1) In any of your examples, I am curious how the container should interpret:

mySingletonBean.setRate(myRate);
myRate.setNewRate(4.55);

The concern I have here is that this update will affect the VM where the POJO assignment was made, but not the other VMs in the cluster. So if this update does affect the local VM and only the local VM, that seems counterintuitive. The only other possibility I could imagine is that the local setRate)( method silently converts local calls into deep copies (which of course is not the calling convention regular Java programmers are used to), to simulate what happens in the other VMs.

2) In your second example, I presume that memory model semantics are applicable, not only in a single VM, but across the cluster?

I am particularly concerned about happens-before being preserved. I presume that the container is responsible for setting locks, and these locks are pessimistic across the cluster. What is the visibility for updates? Presumably any thread, including on the same VM, that is blocked waiting for getRate to acquire the read lock will not get a stale read wrt to setRate’s lock – and what exactly is the monitor that is being used to control the visibility – the singleton bean instance itself? Mainly I am concerned with different threads in the same VM having proper visibility semantics.

3) In your last example, does it mean that changes to the singleton bean are protected inter-thread in the same VM, but in different VMs what does it mean? No changes are replicated? Changes are replicated when the container gets a chance? If the latter, what if setRate makes more than one field state change – how are the changes applied? I guess the container replicates the call with deep copies and repeats the call across the cluster so the local synchronization is preserved.

I guess this question applies to the first example to – how are updates handled across the VM

4) At Terracotta, we are using a convention for concurrency control similar to the second proposal – we have @AutolockWrite and @AutolockRead. Whatever you choose, it would be nice to have an agreed upon set of annotations that are not EJB specific, and factor those annotations into core Java, so annotations like these in pure POJOs could cross domains more easily.

Thanks! Very interesting post. And btw, Terracotta already does everything you are specifying above, and more, but you already knew that

Regards,

Taylor Gautier
Product Manager, Terracotta