Chris McDonough wrote:
It interests me! ;-) I haven't had time to look at the resources you
posted, though...

Oops, I didn't intend for you to analyze those links deeply. I just wanted to see if there was interest in the idea.


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.

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.

The "Shield" experiment proved this can work and doesn't require a lot of code, but it also uncovered some complexity you have to be aware of, like subtransactions.

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


Shane


_______________________________________________
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 )

Reply via email to