This one time, at band camp, tek1 said:
t>At 15:04 03/05/30 -0500, you wrote:
t>> >
t>> > Thanks for explaining how JavaGroups works. Just registering the JDO to
t>> > JavaGroup sounds fairly straight forward. Just trying to get a picture of
t>> > how clustering can be implemented in Castor... So each JDO would fire off
t>> > a "CacheEvent" (types could be OBJECT_ADDED, OBJECT_MODIFIED_,
t>> > OBJECT_REMOVED) to JavaGroups, and each JDO's "CacheListener" would be
t>> > registered with JavaGroups and listen for "CacheEvent"s, and update their
t>> > local cache appropriately, depending on the CacheEvent?
t>>
t>>Yep. The only issue would be synchronizing the CacheEvents so that if
t>>two Castor instances have modified versions of the "same" object and
t>>fire off CacheEvents simultaneously, then you would need a way of
t>>choosing which one to accept and which one to throw out.
t>
t>Hmmm... good point. I'll have to sleep on that one! :) In the meantime,
t>I just created a really rough diagram (hand-written!) of one possible image
t>of the Castor clustering functionality. It's *really* rough (obviously,
t>I'm not an artist!), but perhaps it can serve as an initial diagram to work
t>off of. We can work on a Visio or other computer-generated drawing later,
t>of course. :) I attached it as a .gif (for file size reasons), but if you
t>want the printable .pdf version, let me know.
Looks like a good start for the distributed caching to me. The issue
to be worked out is what to implement as the default (i.e. for stand
alone/default caching). The API must be the same for each one.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
