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

    Exclusive lock is acquired on all nodes not one only

    dmary

      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

          oups, don't care about READ_UNCOMMITTED in conf file, it is SERIALIZABLE I use.

          • 2. Re: Exclusive lock is acquired on all nodes not one only
            dmary

            so, anybody has one solution for my use case ?

            • 3. Re: Exclusive lock is acquired on all nodes not one only
              manik

              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.

              • 4. Re: Exclusive lock is acquired on all nodes not one only
                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 ?

                • 5. Re: Exclusive lock is acquired on all nodes not one only
                  manik

                  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?

                  • 6. Re: Exclusive lock is acquired on all nodes not one only
                    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 ?

                    • 7. Re: Exclusive lock is acquired on all nodes not one only
                      manik

                      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.

                      • 8. Re: Exclusive lock is acquired on all nodes not one only
                        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 ?

                        • 9. Re: Exclusive lock is acquired on all nodes not one only
                          manik

                          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.

                          • 10. Re: Exclusive lock is acquired on all nodes not one only
                            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.