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