There are two clustering options, both implemented as extension
points to plug some outside clustering mechanism. We've never done
any attempts to implement distributed locking, so asynchronous
notifications are the default mode of operation. (Not sure what it
would take to add explicit locking, but theoretically that's a
Option 1: (the one that you've mentioned) Snapshot synchronization.
Each DataDomain in each JVM would broadcast the diffs of the
committed objects. That's a universal mechanism to refresh individual
DataObjects. It also rather brute force, and can generate lots of
network traffic and unneeded app activity.
Option 2: (requires Cayenne 3.0) Query cache synchronization. It was
first mentioned here -  and the early attempts at documenting it
can be found here - . It allows to refresh groups of objects (more
specifically cached query results), not just individual objects. I
don't know whether I can generalize my experience with it, but it
worked extremely well in an environment with a CMS that updates the
data and multiple read-only applications that serve this data on a
high volume public site. Via a "cache group" mechanism you can tweak
what exactly is refreshed on each commit.
I can elaborate some more if you describe the usage patterns that you
envision, and what kind of clustering features you are looking for
(session replication? cache refresh? anything else?)
On Oct 9, 2007, at 2:37 PM, Martin Thelian wrote:
I need some detailed information regarding the capability of
run in a cluster.
I've only found  describing that it's possible to use a "Cross-VM
Cache", either via JMS or javagroups. But how does this work in
What configuration options are available? I've only found some
properties defined in the Class DataRowStore.
Are the notification events, which exchanged between the VMs,
What about concurrent modification of objects located in the cache? Is
there some kind of locking implemented?