> Its been talked about but currently not implemented.I'm catching up on the > conversation and haven't looked at the pointers yet so I have a bit of > reading > to do. > > Are you thinking about using Totem to replicate Entity cache information > in a cluster?
Yes. You can take your pick of concurrency control protocol: 1. Lock locally for reads and possibly roll back if a write arrived with an earlier transaction id. This works well for low sharing and mdb-based transactions, because jms will retry the transaction automatically. 2. Lock globally, shared locks for reads and exclusive locks for writes. This is good if you really cannot handle rollbacks or you have close to 100% sharing so you are destined to wait anyway. It actually turns out that if you have this type of workload _and_ you expect your application to operate at peak throughput then totem provides pretty predictable latency (typically a few ms), which is nice. 3. Multiversion timestamp ordering. See 1, but without read locks. 4. Multiversion two-phase locking. Get exclusive locks for writes, create a new version for reads. This is my favorite. Guglielmo
