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". ;-)

- C

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to