On Fri, 2003-05-30 at 11:01, Shane Hathaway wrote: > The basic idea is that you track changes to session data in a replayable > way. If a conflict error happens, you roll back the session data, bring > it in sync with the current state of the database, and replay the > changes, all during transaction commit. If a conflict happens again, > you repeat the process, up to some user-defined limit.
Right, that sounds really good. > To do this, you have to manage the session data as a single > transactional entity. This was hard to do until I convinced Jeremy to > slip in a new register() method on Connection objects. By overriding > register(), you can get the Connection to manage all changes to its > objects, and the Connection becomes that single transactional entity. So what make up the responsibilities of the session data object itself? > > (We either need an internal project to fail miserably due to conflict > > errors, or I need to stop playing MechAssault on the Xbox so much after > > work and get back to coding after work. ;-) > > Have you tried the commercial version of Tux Racer? I quite enjoy that > simple game. I got a 3D card just so I could play it. ;-) I haven't, because I don't have a PC that is powerful enough to play any games. But if anyone else has an Xbox out there, you can find me via my, uh, gamertag "mcdonc". ;-) - C _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )