Sax <sanxion200..ahoo.com> wrote:
> Mike wrote:
> > 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.
>
> This is the case. Are there any drawbacks to this?
> E.g. that datacontexts use much memory?
Not really. My latest online multiplayer game uses WebObjects/EOF which is
very similar to Cayenne, and I do it with a server app model. EOF isn't
quite as nice for this as Cayenne, and I have to play a lot of games with
locking and object syncronization, though.
> There are multiple cities and each City has a
> container for the Player(s) within it. If the City is
> loaded in a DataContext can the Player have it's own?
> I thought a DataObject could not be shared across
> DataContexts?
Actually, there's no problems sharing dataobjects across DataContexts.
You just create a local instance of each using the
DataContext.localObjects() method.
http://www.objectstyle.org/cayenne/userguide/datactxt/moving-objects.html
> Is this an option? Load all objects with a main
> DataContext. When an object is required for editing it
> is unregistered. When the fields have been updated
> register it back to the DataContext and commit
> changes.
It's an option, but it's not a good one because multiple datacontexts will
do all of your work for you. It also won't work well across threads (see
the other mailing list emails from today on that topic).
You've really got two separate situations.
One, you want to isolate an object from the rest of the players so you can
make changes at the application level.
Then, afterward, you want to commit those changes to the database (and to
other views of the database).
A DataContext will automatically propagate the changes when you commit to
the other DataContexts.
The real trick is to isolate the object at the application level, but this
is really application logic, not database layer logic.
You can either totally remove the object from the view of the player
(probably not practical) or you can just leave a read-only copy for the
other players (which you could do by marking your dataobject as temporarily
read-only -- I'd probably recommend doing this in a global hashtable with
the key being the objectid of the object to modify and the value indicating
whether the object is locked or not -- just make sure you synchronize the
locking).
The beauty of each player having their own datacontext is that changes that
they make won't show up in other datacontexts until they are successfully
committed to the database, but once they are successfully committed, it'll
be automatically propagated.
Unless you have reason for preventing it, there's no need to even lock an
object for updates. Two players can update the same object at the same
time, and it'll just be a case of "last one wins" after both commit. This
is probably what you'd want to happen.
-Mike
This archive was generated by hypermail 2.0.0 : Fri Dec 17 2004 - 21:36:10 EST