Dave, Mike -
I don't have any game development experience (I know I missed all the fun
;-)), so I can't comment on the actual game objects design, but here is a
few notes on the Cayenne end...
Database-level pessimistic lock is definitely an overkill ... any
unexpected conditions may lock your db rows forever and require a server
restart.
The simplest solution would be to use optimistic locking supported by
Cayenne. In addition to giving each player a separate DataContext (which
is always a good idea anyway), create a version or a timestamp column on
each object that is the logical "root" of the changed objects hierarchy
and mark this column to be use dfor optimistic locking in CayenneModeler.
Users won't be able to override each other changes, however the obvious
downside is that a lock kicks in only during save, so a user can waste her
time editing an object only to get an error on commit..
A workaround to that maybe a notification sent to the user when another
user saves the changes so the room state is updated externally. Cayenne
supports that via DataContextDelegate...
And finally if you real want just one user to modify the room, you can
have a custom auto-expiring lock stored somewhere in a separate table,
that is committed to DB when the users starts her first edit. This way you
can even display the status of editing via the UI to other users.
So you have a number of options here...
Andrus
This archive was generated by hypermail 2.0.0 : Fri Dec 17 2004 - 11:04:41 EST