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
But if anyone else has an Xbox out there, you can find me via my, uh,
gamertag "mcdonc". ;-)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -