How does Terracotta work in this situation?

Question

So lets say I have an N sized server array set up like so:

alt text http://www.terracotta.org/web/download/attachments/43909161/ServerArrayMirrorGroup.png

I have a simple JavaBean/POJO:

package example;

public class Person {
  private OtherObject obj;

  public void setObj(OtherObject theObj) {
    synchronized (this) {
      obj = theObj;
    }
  }

  public OtherObject getObj() {
    synchronized (this) {
      return obj;
    }
  }
}

Now if one of the Clients calls Person.setObj(OtherObject) on a Person Object in the TC root (data structure), is the synchronized block (in Person.setObj(OtherObject)) on that client held:

1) Until all N of the Servers in the N sized server array have been synchronized/updated with that Person.obj attribute?

or

2) Until the "active" server has been synchronized with that updated Person.obj attribute? Then the other (N-1) servers in the array are synchronized as possible?

or

3) Some other method that I am over looking?

Just FYI: synchronizing in this case does nothing because assignment of a reference is atomic. — cletus, May 02 '09 at 17:30
@cletus: Not true. Synchronization introduces a visibility guarantee for the reference assignment to other threads, and in this case to other servers too. Without synching, no other thread in the JVM or cluster is guaranteed to ever see that the variable has changed. — Chris Vest, May 03 '09 at 00:15

score 5 · Accepted Answer · answered May 04 '09 at 14:24

The answer is not really 1 or 2. Objects are striped across the server mirror groups. The first time this field is set, a transaction is created and that mirror group chosen for that first transaction will "own" the object after that.

With respect to both 1 and 2, not all active server groups need to be updated so there is no need to to wait for either of those conditions.

You can find more info at the Terracotta documentation about configuring the Terracotta server array:

http://terracotta.org/web/display/docs/Terracotta+Server+Arrays

From a locking point of view, the clustered lock on this Person object would be held (mutual exclusion across the cluster) while performing the object modification. The scope of the synchronized block forms the transaction mentioned above. In the getObj() method, you could configure this as a read lock which would allow multiple concurrent readers across the cluster.

score 3 · Answer 2 · answered May 03 '09 at 22:52

Assume that everyone else has a reference to your object and can touch it while/before/after you do. Thus the solution would be to add locks, and

obtain lock
modify the object
release lock

And that's exactly what synchronized does... it creates a queue and the synchronized method can't be called more than once... but the underlying object might be touched if it's referenced somewhere.

see:

This is all true but it doesn't actually answer the question at all? — Alex Miller, May 04 '09 at 20:06

score 0 · Answer 3 · answered May 03 '09 at 00:31

I'm not familiar with their (Terracotta) implementation, but from a JMM standpoint, it should take a cluster-wide lock. However, this example is very simple; just a change of a reference, and that may cause it to be converted into something that is more like a volatile write, and completely avoid locking.

But, if you do non-trivial stuff in your synchronized block, then I would assume that TC pessimistically takes a cluser-wide lock at the start of the synchronized block. If they didn't, they would be at odds with the JMM spec. as I understand it.

In other words, your option #1. So, be careful what you share in the cluster, and use immutable objects and java.util.concurrent.* data structures when you can - the latter is getting special intrinsic love in TC.

How does Terracotta work in this situation?

3 Answers3