[MUD-Dev] Persistent Worlds
Miroslav Silovic
silovic at zesoi.fer.hr
Wed Feb 28 21:13:42 CET 2001
"Ryan Rhodes" <ryanshaerhodes at hotmail.com> writes:
> Sounds like J C is using the dereferencing to trap it as well. Ok,
> so I won't be able to do it in java with a simple description in
> C++. Java has automatic dereferencing so I have no control over it
> whatsoever. Operator overloading isn't allowed either. Anyone have
> any other methods to "trap" object accesses?
> I was reading up on java's dynamic proxy class. You can tell java
> the object you want a proxy for and it hands you a generic proxy.
> Methods calls on the proxy are echo'd to the original object through
> the proxy. This sounds like the same basic idea as the wrapper
> except you've added extra overhead on every method call instead of
> on every dereference. If I build my world out of proxies instead of
> actual objects is this going to hurt performence significantly?
This is the method I planned to implement for TOM persistence, as
well. Yes, it's a performance hit (at least in TOM, I can't talk about
Java with the same confidence) because instead of a single table
lookup and dispatch, it will dispatch to the proxy object method that
has to redo the method lookup. I'm not sure if it's *huge* performance
hit, though - it really depends on what you intend to do.
What I ended up doing is morphing the objects by overwriting their
class record pointers. That way the nonloaded objects behave like
proxies, but once you load them from the db, the proxy memory is
actually overwritten with the real object data. There's one more
'special' class that keeps the object memory but still sends the
notifies around (this is used to keep track of the loaded but unused
objects - they eventually get swapped off).
I'm not sure if this can be done in Java, especially since I had to
add a few features into the TOM runtime library to support this.
--
How to eff the ineffable?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list