This is just a vague idea, but I would think that it would be nice to have
an API for cache updates independent from synchronization/notification
transport used. I guess I need to read through the JCP and JCS docs (yeah
right, I barely have time to drink coffee to keep me up these days:-)). The
way I see it is a default implementation with a minimal configuration and
overhead (say UDP broadcast), that does not require RMI, JMS or external
dependencies and uses the simplest possible discovery mechanism.
After such API and default implementation is defined, there maybe JMS or
RMI or other transport modules that use other, heavier approaches. But then
again, maybe if I try JCS, I may change my mind about it...
Also (I guess only after I retire and have my life back under my control
:-)) I was thinking that such things as cache policies should be
configurable by CayenneModeler, moving it closer to the promise of a
*deployment* tool, not just the mapping.
Good luck EventObserver!!
Andrus
At 06:58 PM 1/3/2003 +0100, Holger Hoffstätte wrote:
>I cannot say much about your other issues (except that I couldn't get the
>point behind the partial objects), but I thought a bit about the cross-VM
>notification issues. The usual approach - manually throwing EOGlobalIDs,
>err, ObjectIDs over the fence via RMI or XML-RPC works but is tiresome,
>not failsafe and really only useful for ad-hoc hacks. Much better to have
>a generalized messaging solution that deserves the name: JMS is the
>obvious candidate. But JMS alone 'only' takes care of the messaging
>(although it's pretty flexbile, synchronous/asynchronous, guaranteed
>delivery, IIRC can use different transports etc.; I think newer TopLink
>uses JMS too) and several people realized that more generalized
>infrastructure for caching is needed. See:
>http://www.jcp.org/en/jsr/detail?id=107 for something that will likely
>show up in J2EE sooner or later. Its ideas are based on JCache by Oracle
>and there's at least one person with a clue on the group (from Gemstone),
>so there's actually hope. :-)
>Another interesting thing to look into might be JCS:
>http://jakarta.apache.org/turbine/jcs/ which is also used by Hibernate
>('that other' mapping framework) for cross-VM consistency. JCS uses RMI
>and offers a very, very interesting set of features. I don't know how
>difficult it might be to set up an (probably optional)
>DataContextChangeEventObserver that distributes updates/deletes to other
>VMs; a look at Hibernate will probably help.
>
>Dirk & I had some interesting brainstorming today about the EventObserver
>stuff; we found a couple of points that we could improve, so once we have
>this in place we can look at trying to throw Events around over a network.
>Guess I'll have to dig out my TopLink again sand see how we can improve on
>that!
This archive was generated by hypermail 2.0.0 : Fri Jan 03 2003 - 23:27:55 EST