1 Reply Latest reply on Mar 3, 2010 4:07 AM by mircea.markus

    Lock durations and catchEvent() callback events

      Hi, one more question:

       

      Assumptions:

      - DIST

      - each node maintains a secondary "bookkeeping" based on cache data (e.g. maintains secondary indices to the data, which are always derived and maintained based on cache data dynamically and are therefore redundant in nature)

       

      Questions:

      Q1: in case the local node makes the put-operation, how do the locks behave with respect to:

           - catchEvent() callback when e.isPre() == true

           - catchEvent() callback when e.isPre() == false

      Are the acquired locks locked during both callback call events? Or during any of them?

       

      Q2: as above, but in case some other node makes the put-operation (which is also currently partitioned to the node in question)

      Are the acquired locks locked in both callback call events?

       

      I'm thinking the correct strategy to maintain the secondary data (which in this particular case we need and want to maintain programmatically and separately from Cache).

        • 1. Re: Lock durations and catchEvent() callback events
          mircea.markus

          Q1: in case the local node makes the put-operation, how do the locks behave with respect to:

               - catchEvent() callback when e.isPre() == true

               - catchEvent() callback when e.isPre() == false

          Are the acquired locks locked during both callback call events? Or during any of them?

          yes, the current thread (or tx associated with it) does have the locks (locked) during both calls.


          Q2: as above, but in case some other node makes the put-operation (which is also currently partitioned to the node in question)

          let's say that we have A, B nodes and k1 the key to be updated, residing on B (and backuped on some other node C, numOwners=2).

          On A: cache.put(k1, "val1"); //this will call a local event listener, with lock held on k1

          then, when distribution will update the remote value on B, another listener will be called in B's JVM, again, with locks held.