Sax <sanxion200..ahoo.com> wrote:
> I'm looking into using Cayenne for an online SIM-like
> game written in Java
> and I need some help with design/implementation.
>
> I have the following classes:
> House, Room, Furniture, Player
>
> The Player can edit a Room which means it should
> basically be "locked" while the
> editing is going on. Let's say the Player has added a
> bunch of Furniture to the
> Room, changed the roof, wallpaper and so on. This is a
> process of 10-15 minutes
> involving many objects and changes of fields and
> lists. The changes made to the
> Room should only be saved when the Player hits the
> "save button", upon which
> Cayenne stores all changes to the database. This works
> well with one Player, but
> not 15-30. Because whenver anyone hits the "save
> button" Cayenne will save any
> changes to any object across all Room(s).
There's currently no support in Cayenne for pessimistic locking (which is
what you're describing), but there's probably no need for it in your current
situation. Is there a reason you can't allow each change to happen
immediately? Even if there is, you really want to look the view of the
object from the app point of view, and not from the database.
Actually, I guess there's two situations:
1) "server app" which has all datacontexts in memory for all players, and
thus all objects are shared in which the above is true.
2) client app that reads directly from the database. In this case, it
doesn't matter.
As for your saving question.
Give each player a separate DataContext.
Only changes made in a specific context will be saved when you tell that
context to commitChanges.
If it's a web-based game, you can tie the DataContext to the session.
If it's a TCP/IP game, you'll probably have a separate thread for each
player, and you can tie the context to the thread.
I wrote a game like this back in the early 90s in C using flatfiles.
You might find it more flexible to define every object as a container.
Each object would have an inside and outside description/view, based on what
other objects are siblings in the parent container's "contents" list. So
you'd see the parents inside view and the other siblings outside view. You
also allow a container to be transparent/invisible in one or both
directions.
This allows you to do all sorts of fun things. You can attach
commands/actions to the containers themselves, allowing context-sensitive
actions. You can simulate things like cars, dressers, airplanes, etc.
You can then design specific subclasses of Container to provide standard
behavior for House/Room/Furniture/Player, but you will always have the
flexibility to change behavior or add more kinds of objects.
My "database" ended up having fields like Container, Command, Description
-Mike
This archive was generated by hypermail 2.0.0 : Fri Dec 17 2004 - 10:43:54 EST