Andrus wrote:
> 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
I spent some more time with them and have to revise my opinion a bit: they
seem to be genuine caches with the focus on saving object construction and
keeping resource usage under control e.g. by using LRU pools etc. - I
don't think this is what we need for a first cut since all the object
instantiation logic is already in Cayenne and caching is already provided
by the existing snapshot manager.
> 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.
I had JavaGroups (http://www.javagroups.com/) on my 'list of things to
check out' for quite some time and - triggered by some discussion about it
on wo-dev - looked at it again. It is really much closer to a relatively
lightweight broadcast mechanism than JCS. It uses reliable multicast for
loosely coupled group communication and is the mechanism used by JBoss for
clustering. Frankly I didn't even know that you could make multicast
reliable..
With some of the things Dirk and I whipped into the EventObserver stuff,
event topics with namespaces (we all them 'subjects') should allow for
dynamically detecting cooperating instances, so that only VMs which have
something in common talk to each other. Local event delivery has made some
progress too, we detect GC'ed observers via WeakReferences and skip then
during notification, avoiding the dreaded 'performSelector sent to freed
object' symptom that came up in ObjC when you forgot to retain your
notification observer.
Holger
This archive was generated by hypermail 2.0.0 : Wed Jan 08 2003 - 14:57:14 EST