10 Replies Latest reply on Jun 16, 2008 7:55 AM by dmary

Exclusive lock is acquired on all nodes not one only

dmary Jun 12, 2008 11:54 AM

Hi all,

I use TreeCache (JbossCache 1.4.1 SP3 with Jboss 4.0.5GA) with a cache configured in a clustered environnement.
I set in PESSIMISTIC/SERIALIZABLE mode and I want to lock only one node when I read or write to it.
For example, if I have /root/subroot/A and /root/subroot/B, I read node A, I want to have an exclusive lock on it , but I want also to read with another transaction node B.

But at this moment, the cache is entirely locked! I cannot read node B at all.

<?xml version="1.0" encoding="UTF-8" ?>
<server>
 <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
 <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=MyTreeCache">
 <depends>jboss:service=Naming</depends>
 <depends>jboss:service=TransactionManager</depends>
 <depends>jboss.jca:service=DataSourceBinding,name=my-ds</depends>

 <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>
 <attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
 <attribute name="IsolationLevel">READ_UNCOMMITTED</attribute>

 <attribute name="CacheMode">REPL_SYNC</attribute>
 <attribute name="ClusterName">
 master-${jboss.partition.name:Cluster}
 </attribute>
 <attribute name="ClusterConfig">
 <config>
 <UDP mcast_addr="${jboss.partition.udpGroup:228.2.2.14}"
 mcast_port="48252" ip_ttl="${jgroups.mcast.ip_ttl:2}"
 ip_mcast="true" mcast_send_buf_size="150000"
 mcast_recv_buf_size="80000" ucast_send_buf_size="150000"
 ucast_recv_buf_size="80000" loopback="false" />
 <PING timeout="2000" num_initial_members="3"
 up_thread="false" down_thread="false" />
 <MERGE2 min_interval="10000" max_interval="20000" />
 <FD shun="true" up_thread="true" down_thread="true" />
 <VERIFY_SUSPECT timeout="1500" up_thread="false"
 down_thread="false" />
 <pbcast.NAKACK gc_lag="50" max_xmit_size="8192"
 retransmit_timeout="600,1200,2400,4800" up_thread="false"
 down_thread="false" />
 <UNICAST timeout="600,1200,2400" window_size="100"
 min_threshold="10" down_thread="false" />
 <pbcast.STABLE desired_avg_gossip="20000"
 up_thread="false" down_thread="false" />
 <FRAG frag_size="8192" down_thread="false"
 up_thread="false" />
 <pbcast.GMS join_timeout="5000"
 join_retry_timeout="2000" shun="true" print_local_addr="true" />
 <pbcast.STATE_TRANSFER up_thread="false"
 down_thread="false" />
 </config>
 </attribute>
 <attribute name="InitialStateRetrievalTimeout">6000</attribute>
 <attribute name="SyncReplTimeout">10000</attribute>
 <attribute name="LockAcquisitionTimeout">4000</attribute>

</mbean>
</server>

How can achieve my use case ?

1. Re: Exclusive lock is acquired on all nodes not one only

dmary Jun 12, 2008 11:55 AM (in response to dmary)

oups, don't care about READ_UNCOMMITTED in conf file, it is SERIALIZABLE I use.
Actions
2. Re: Exclusive lock is acquired on all nodes not one only

dmary Jun 13, 2008 3:11 AM (in response to dmary)

so, anybody has one solution for my use case ?
Actions
3. Re: Exclusive lock is acquired on all nodes not one only

manik Jun 16, 2008 5:06 AM (in response to dmary)

SERIALIZABLE will obtain a SERIALIZABLE lock on the entire cache.

You really won't have much concurrency at all using SERIALIZABLE. I'd recommend R_R.
Actions
4. Re: Exclusive lock is acquired on all nodes not one only

dmary Jun 16, 2008 5:18 AM (in response to dmary)

Well, I don't want any concurrency.
The fact is if one node of the farm is reading one node of the tree cache, other node won't we allowed to read .

but with REPEATABLE_READ, all nodes can read cache.

if the first node read, override with same data, re - read, and I choose R_R, will it lock for other node in farm ?
Actions
5. Re: Exclusive lock is acquired on all nodes not one only

manik Jun 16, 2008 5:43 AM (in response to dmary)

If you don't want any concurrency then that is exactly what you have - when /root/subroot/A is read, no one can read any other node. :-)

Perhaps what you want is different caches for each subroot then?
Actions
6. Re: Exclusive lock is acquired on all nodes not one only

dmary Jun 16, 2008 5:51 AM (in response to dmary)

no , what I want exactly is :

1) node 1 read /root/subroot/A
2) other nodes cannot read /root/subroot/A as node 1 is reading it (locked)
3) node 5 read /root/subroot/B
4) other nodes cannot read /root/subroot/B as node 5 is reading it (locked)
5) node 1 finishing reading (and writing optionally) on A, so A is available for others (unlocked)
6) node 5 finishing reading (and writing optionally) on B, so B is available for others (unlocked)

so do u see how I can achieve it ?
Actions
7. Re: Exclusive lock is acquired on all nodes not one only

manik Jun 16, 2008 6:56 AM (in response to dmary)

If you were using 2.X there is a setForceWriteLock() option which would have worked for you.

As a workaround, you could do this:

1. Configure your cache with R_R.
2. Start your transaction.
3. Whenever you need to READ a node, first WRITE a dummy value to it. E.g., cache.put("/root/subroot/A", "dummy", null); This will force a write lock on the node, and no other thread will be able to read it.
4. Perform your READ.
5. Commit your tx.
Actions
8. Re: Exclusive lock is acquired on all nodes not one only

dmary Jun 16, 2008 7:15 AM (in response to dmary)
well I understand ur point of view.

I'm exactly use TreeCache (1.4.1 SP3 with Jboss 4.0.5GA) in this way :

put all my objects at /root/subroot , so I have :
/root /subroot Integer1 : Object1 Integer2 : Object2 Integer3 : Object3

instead, I must have as you said :
/root /subroot / Integer1 Key1 : Object1 (Key can be same as Insteger1 or anything else) dummy : null /Integer2 Key2 : Object2 (see above) dummy : null /Integer3 Key3 : Object3 (see above) dummy : null

It is right ?

Otherelse, do u think it is a good thing to let "dummy" object staying in my cache or shall I have to delete it just before Tx finished ?
Actions
9. Re: Exclusive lock is acquired on all nodes not one only

manik Jun 16, 2008 7:27 AM (in response to dmary)

Yes, having each one in a separate node will allow you to lock each key/value pair separately - if that is what you want to achieve.

Re: dummy objects, you may as well leave them there since a put() when the key/value already exists is faster than if it didn't exist, plus you don't have to incur the cost of a remove.
Actions
10. Re: Exclusive lock is acquired on all nodes not one only

dmary Jun 16, 2008 7:55 AM (in response to dmary)

You're the boss !

thks a lot, I can achieve it with R_R and your trick.

I will leave dummy key as I understand it is much better than other solution , for the cost of time.

thanks again.
Actions

Go to original post