Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi,
I'm asking myself questions about locks and transactions in terracotta.

I have seen :

Terracotta transactions are sets of clustered object changes that must be applied atomically. Transactions are bounded by lock acquisition and release. When a clustered lock is acquired by a thread, a Terracotta transaction is started and all changes to clustered objects made within the scope of that lock are added to that transaction. When the lock is released, the Terracotta transaction is committed.

and rollback should be managed by end users.

I'm trying to move an element from one map to another like this :

Code:

 final ClusteredMap<Long, String> iMap_ = toolkit_.getMap("imap");
 final ClusteredMap<Long, String> oMap_ = toolkit_.getMap("omap");
 final ReadWriteLock txLock = toolkit_.getReadWriteLock("mytestLock");
 txLock.writeLock().lockInterruptibly();
 try {
       //Lock the row to avoid any modification during transfert
       final ClusteredLock lock = Imap_.createFinegrainedLock(key);
       lock.lock();
       try {
           Omap_.put(key, iMap_.get(key));
           //CRASH HERE
           Imap_.removeNoreturn(key);
       } finally {
            lock.unlock();
       }
      
 } finally {
     txLock.writeLock().unlock();
 }

But with some crash test, i'm being able to have the Object in both Imap and Omap.

Is there a way to have a commit only when no error (looking to java documentation, a lock should be call in finally)?

Where is my error ?

Regards
Hervé

Hervé,
The problem is that you have 2 locks playing here. You do create the fineGrainedLock based on Imap, now, when mutating Omap, there is yet another lock for that mutation acquired.

If you want to make these changes atomically, you need a single lock. One way would be to create Omap "unlocked". That way mutation would need their own (external) lock. Mutations to Omap happening solely under the explicit lock from Imap, would guarantee a single transaction and atomicity for these 2 mutative operations.

Hi,
thanks for the answer.

Does it mean that something like :
Code:

 //Lock the row to avoid any modification during transfert
        final ClusteredLock lock = Imap_.createFinegrainedLock(key);
        lock.lock();
        try {
            Omap_.put(key, iMap_.get(key));
            //CRASH HERE
            Imap_.unlockedRemoveNoReturn(key);
        } finally {
             lock.unlock();
        }

would work ? it seems a bit strange as the lock has been defined for one entry in IMap.

I removed the "global" tx lock as it was not useful for my behavior and it does not allow copy of different entries concurrently.

Regards
Hervé

Hi,

One way would be to create Omap "unlocked"

As i am using the Terracotta toolkit, I can't see how to create this map "unlocked".

How can i create this map "unlocked" ?

Regards
Hervé

Sorry! I meant to reply to this for a while already...
Now you'll quickly understand why that didn't happen before though. Seat belt fasten ? ;)

You might want to have a look at http://code.google.com/p/terrastore/source/browse/src/main/java/terrastore/internal/tc/TCMaster.java

In there you'll see a couple of things happening:
1/ the connect() method, will make sure we get a Client back
2/ the enum ClusteredTypes, list some types you'll want to instantiate in your case: NullLockStrategy, and ClusteredDistributed(Server)Map. Probably want to leave the Server bit out in your case.
3/ getOrCreateMap(String) will access a "root", which is a map, from the toolkit, that will hold all custom instantiated Maps, keyed by name. That's what the toolkit does for you when calling getMap(String):ClusteredMap btw
3.1/ This last call also shows how to create a custom type (would be ClusteredDistributedMap for you), using some special constructor. The one you care about is org.terracotta.collections.ConcurrentDistributedMap#ConcurrentDistributedMap(LockType, LockStrategy<? super K>)

I hope this all makes sense and you'll managed to work your way through with those bits. Now, future release will make all that much easier!

BTW, we are in the process of revamping some of the Toolkit interfaces (Toolkit 2.0) for the next major release. It will address this exact issue by providing an AtomicToolkit interface that u can use to create Atomic transactions explicitly.

Hi,
thanks for the answers.
I will look to the provided code and your explanations.

It's a good news to known that the next major release will address the issue :).

Regards
Hervé