we're proxying for a client, we now have to give up our ClientObject to anyone
who wants it, so that they can do access control checks.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5593 542714f4-19e9-0310-aa3c-eee0fc999fb1
the local JVM (in general we'll use them on the server). The idea is to get rid
of all of our messy transients in BodyObject on down (and possibly other
places) and encapsulate them in a nice ClientLocal object (extended to
BodyLocal and on down).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5472 542714f4-19e9-0310-aa3c-eee0fc999fb1
thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5400 542714f4-19e9-0310-aa3c-eee0fc999fb1
importing receivers from their senders to satisfy their links.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5333 542714f4-19e9-0310-aa3c-eee0fc999fb1
directly to stderr. Logging an exception with the associated warning does the
right thing and logs the stack trace via the logging system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5318 542714f4-19e9-0310-aa3c-eee0fc999fb1
generic array type handling and other niggling bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5267 542714f4-19e9-0310-aa3c-eee0fc999fb1
I myself couldn't even remember and had to trace through code.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5179 542714f4-19e9-0310-aa3c-eee0fc999fb1
allowing the use of annotations to customize transport for
DObject fields and service/receiver methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5099 542714f4-19e9-0310-aa3c-eee0fc999fb1
DObject. There will never be multiple instances with the same oid that
represent "equal" objects and it's possible that in certain (controlled and
limited) cirumstances, objects with different object managers might have the
same oid even though they are different objects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4853 542714f4-19e9-0310-aa3c-eee0fc999fb1
interface to a list of listeners. Also made RootDObjectManager a RunQueue so
that we can pass around references to the interface rather than requiring a
PresentsDObjectMgr.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4789 542714f4-19e9-0310-aa3c-eee0fc999fb1
(pre-applied and) posted before we received our object but processed (and hence
dispatched to us) after we received our object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4715 542714f4-19e9-0310-aa3c-eee0fc999fb1
fake Entry implementation. This also avoids breakage if a DSet entry's key
itself implements DSet.Entry (which just happened for the first time in Narya
history).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4673 542714f4-19e9-0310-aa3c-eee0fc999fb1
except that messages will never leave the server. If generated on a client,
they'll go to the server and be processed like a normal event there
(event handlers will be called) but the event will not leave the server and
be sent to subscribing clients.
Changed the ManagerCaller used by PlaceObjects to use ServerMessageEvents.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4648 542714f4-19e9-0310-aa3c-eee0fc999fb1
queue up an invoker unit which would go off and do some database stuff and then
by the time it came back and was ready to publish its results to a distributed
object, the object in question would have been destroyed for any of a variety
of fairly natural reasons (client disconnected or logged off, game was
abandoned, dog ate homework).
One "solution" to this problem would be to litter our games' code with
thousands of calls to isActive() in the handleResult() methods of our invoker
units. We've done a bit of that in Yohoho but I've resisted starting down that
path in our other games.
Another solution would be to create an Invoker.Unit wrapper that takes a
reference to the distributed object (or objects) that it will be modifying and
have the common unit code check that the object(s) in question are still alive
at the end of the asynchronous operation and not call handleResult() if they
are not. This has numerous problems: what do you do if one object is alive but
not another, how do you incorporate this functionality in with the numerous
other Invoker.Unit derivations we have that simplify our lives in other ways
(without getting crazy and starting to use something like AOP), do you silently
abort the operation or log something?
So instead, I've come around to the idea that this is simply a dirty fact of
life in asynchronous programming and the fact that we can accept modifications
to distributed state after the distribted object in question is dead is a good
thing. We used to log a warning every time this happened and freak out even
more substantially if one tried to start a transaction on a dead object. Now we
will simply log an informational message (I don't think this sort of thing
should be silently ignored because there are some cases where it is an
indication of incorrect code, those are simply more rare). We will also allow a
transaction to be started on a dead object and when the transaction is
committed, all the events involved will be dropped just like a single
modification would have been dropped on that object.
This allows the most sensible thing to happen which is any results that are
published to still live objects will actually be published and results
published to dead objects will be dropped without making a big fuss. Since a
dead object by definition cannot have subscribers, no one could possibly have
cared about the dropped events anyway.
Also widened.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4545 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne