Terracotta Discussion Forums

The reason, why I tried lock upgrades was, that I was playing with lock in general, so the upgrade of lock was one of the use case.

I tried to prepare pattern to simplify the usage of read locks. Our use case is, that in most cases we perform only read operations. My initial idea was, that I can perform read lock automatically around each 'transaction' (= e.g. remote call) on shared data, which is related to the transaction and if the transaction will need to write to the shared data, it can upgrade the lock to write level.

But I have understood, that this leads to deadlocks if there are more than one such requests which need to upgrade lock - this is clear. Also the fact, that multiple threads which are running on same VM with lock level read works in actually as exclusive (= standard Java locks) destroyed my idea. So the last thing which stays from my idea is the test itself ;-)

The environment was following:
-- Terracotta DSO 2.3-stable0
-- Windows XP
-- Java 1.5.0_08

The source code of the test I have provided last night [= day for you ;-)] to steve.

Radim

Hm, sorry - I have made different test and I'm still not successful.

Currently I have just 2 threads, which infinitively perform:
-- one thread just acquires read lock
-- second thread acquires read lock and tries to upgrade it to write lock (see the code snippets, which I have sent first time)

Following statements are from documentation:
-- No thread may acquire a write lock if any thread holds a read lock.
-- No thread may acquire a read lock if any thread holds a write lock.
-- No thread will be granted a read lock if any thread is contending for a write lock

According above mentioned rules, my program should not go into deadlock (I hope), but it again ends with deadlock.

Here is the output of my program, where you can see the processes.

Small legend first:
-- R = the read lock thread
-- U = thread which tries to upgrade lock
-- 'competing for read lock' = before synchronized block
-- 'read lock acquired' - inside of synchronized block
-- 'read lock released' - after synchronized block

And the output:
Code:

 R: competing for read lock
 R: read lock acquired
 U: competing for read lock
 R: read lock released
 R: competing for read lock
 U: read lock acquired
 U: competing for write lock

-> deadlock

Couldn't be a problem, that write lock can't be obtained even if some thread is competing for read lock (and not 'contains read lock' like it's written) - because this is the behavior, which I see.

Thank you for patience ;-)
Radim

Thank you Steve.

Now I see it too - it's classical deadlock situation.

Radim

In DSO documentation is statement: "Read locks allow multiple threads to acquire the lock at a time, ..."

I have performed test (just in single VM + Terracotta server), where more threads are acquiring read lock on same shared object. But I have seen, that not more threads are able to acquire the lock in the same time, thread can obtain the lock only if other thread releases it. I use auto locked method with level read and I'm synchronizing over the shared root object.

So, it's the statement in documentation right?
Does it work according this statement also inside one virtual machine or it's just valid for multiple VMs (= more threads, but each running on different VM, can simultaneously read on shared object)?

Second possibility is, that I have something wrong in my program and the read locks should work like it is written in the documentation. In this case you actually change the meaning of Java's 'synchronized' keyword, because normally synchronized sections are exclusive = write locks. Means that, that if I run the application with Terracotta it behaves differently (synchronized sections with possible levels read or even concurrent) , than if I run it without Terracotta (only JVM's write locks)?

Radim

Today I'm playing with locking in Terracotta - specially I was interested in possibility to upgrade locks.

I start two threads, which both do in infinite loop call of method acquireReadLock(). The methods looks like following:
Code:

 /* method auto-locked with read level */
 public void acquireReadLock() {
     synchronized(sharedRoot) {
        acquireWriteLock();
     }
 }
 
 /* method auto-locked with write level */  
 public void acquireWriteLock() {
   synchronized(sharedRoot) {
    }
  }

I have problem, that my program seems to be in deadlock after while.

Do I something wrong or did I have found a bug?

Radim

Thank you again Taylor.

I was still wrong in my statement, now it's really crystal bright for me ;-)

Thank you for your quick answers.

Sorry, but I'm still not 100% sure if I understand it right, may be because of my English ;-)

I have performed another tests and my current imagination is following:
-- constructor of shared root and constructors of inner objects (which are created during constructor of root object) are called on all cluster nodes
-- the assignment operations which writes to the attributes of shared instances are not performed
-- so the newly created instances have no references in the heap and are candidates for garbage collector
-- these constructors could be still usable because of their "side effects"

Is my understanding now right?

Radim

The kind of data which I have to share has following character:
-- there is such like shared map with much of data (values of this shared map usually contains again maps, I will call them submaps)
-- write operations to this data is mainly concentrated to the initializing process
-- after initialization is the shared data changed rarely
-- there is frequently used read operation on this shared data

The typical use case is, that I get particular submap from the main share map and I perform some read operation on the data containing in this map and objects references from this map. The code which reads this data is quite distributed around the source code, so it would be difficult to create read locks for this data.

I have found in some discussion, that read locks are not mandatory - so I don't currently use them. Since now it works fine.

My questions are according performance of such code.

Interesting would be to know following answers:

1. When I perform read operation on shared data, which didn't obtain read lock, does it cause to communicate with Terracotta server before each read operation on my shared objects?

2. Which principle is used to inform the local JVM copy of object, which just reads the shared data, that the data is dirty?
In other words, what happens if the shared data is changed?
How are informed the cluster members, that the data is dirty?

I have question according the process which is performed when I instantiate an object which is already present/shared in Terracotta server.

My first imagination was, that the constructor on this object is not called and the object data is reconstructed according to data loaded from Terracotta server (like in serialization).

But, when I have performed some tests, I have seen, that the constructors of these objects are called.

Can somebody please describe, what's happening behind the scene when I create instance of object which is already shared?

Thanks, Radim

Is there some possibility to combine more Terracotta clustering products together in one Terracotta server?

I would like to use for example T. for Spring for my beans but also T. Sessions for session replication.

Is there some elegant way how to maintain shared register of cluster nodes?

I think, that it's quite easy to maintain cluster shared list of cluster nodes where I can on startup add members and on shutdown remove them.

But what I can do if some cluster node dies without unregistering? Terracotta DSO server probably knows about it. But is there some possibility to be informed of such event?