2 Replies Latest reply on Mar 15, 2005 12:13 PM by belaban

    Synchronous replication (REPL_SYNC) does not block the calle

    canghel

      Hi,

      I am using the tree cache within JBoss 3.2.6. It seems that REPL_SYNC does not block the caller.
      I have two caches each of them set with REPL_SYNC and isolation level SERIALIZABLE.
      The following scenario works on a single node but fails in a cluster with 2 nodes:
      1. I place an object in the first cache
      2. I place another object in the second cache
      2.1 I override _put and I search in the first cache for the first added object but nothing is found; I need to find it to set it as an attribute for the 2nd object before adding this object to the second cache; in the end I call super._put to place the object normally in the cache

      I checked the logs. On the machine were the problem appears (not the one actually starting the put call but the other one where the objects have to be replicated) I can read the following:

      17:21:44,743 INFO [STDOUT] 2005-03-14 17:21:44,743 DEBUG cache.AglCache (TreeCache.java:2351) - _put(<CLAUVPC:1966>:10, "/AGL/AglCoreScu/AglCoreScu:1", 1, [AglBaseCoreObject: key: 1 configuration: null])
      17:21:44,946 INFO [STDOUT] 2005-03-14 17:21:44,946 DEBUG cache.AglCache (TreeCache.java:2740) - prepare(): run prepare
      17:21:44,946 INFO [STDOUT] 2005-03-14 17:21:44,946 DEBUG cache.AglCache (TreeCache.java:1585) - get(, "/AGL/ScuConfiguration/ScuConfiguration:1", 1, "true")
      17:21:44,946 INFO [STDOUT] 2005-03-14 17:21:44,946 DEBUG cache.AglCache (TreeCache.java:2351) - _put(<CLAUVPC:1963>:9, "/AGL/ScuConfiguration/ScuConfiguration:1", 1, [ScuConfiguration:[AglConfiguration: key: 1 name: R1_SCU] OFF_STEP: 0 type: AirfieldZone maxAvailableSteps: 3 isMaster: true isFlipFlop: true isControlAndFeedback: true { } ])
      17:21:45,102 INFO [STDOUT] 2005-03-14 17:21:45,102 DEBUG cache.AglCache (TreeCache.java:2790) - commit(): called to commit cache with gtx <CLAUVPC:1963>:9
      17:21:45,102 INFO [STDOUT] 2005-03-14 17:21:45,102 DEBUG cache.AglCache (TreeCache.java:2803) - commit(): releasing lock write owner=<CLAUVPC:1963>:9
      17:21:45,102 INFO [STDOUT] 2005-03-14 17:21:45,102 DEBUG cache.AglCache (TreeCache.java:2803) - commit(): releasing lock read owners=[<CLAUVPC:1963>:9]
      17:21:45,102 INFO [STDOUT] 2005-03-14 17:21:45,102 DEBUG cache.AglCache (TreeCache.java:2803) - commit(): releasing lock read owners=[<CLAUVPC:1963>:9]
      17:21:45,102 INFO [STDOUT] 2005-03-14 17:21:45,102 DEBUG cache.AglCache (TreeCache.java:2808) - commit(): removing local transaction key null
      17:21:45,227 INFO [STDOUT] 2005-03-14 17:21:45,227 DEBUG cache.AglCache (TreeCache.java:2790) - commit(): called to commit cache with gtx <CLAUVPC:1966>:10
      17:21:45,227 INFO [STDOUT] 2005-03-14 17:21:45,227 DEBUG cache.AglCache (TreeCache.java:2803) - commit(): releasing lock write owner=<CLAUVPC:1966>:10
      17:21:45,227 INFO [STDOUT] 2005-03-14 17:21:45,227 DEBUG cache.AglCache (TreeCache.java:2803) - commit(): releasing lock read owners=[<CLAUVPC:1966>:10]
      17:21:45,227 INFO [STDOUT] 2005-03-14 17:21:45,227 DEBUG cache.AglCache (TreeCache.java:2803) - commit(): releasing lock read owners=[<CLAUVPC:1966>:10]
      17:21:45,243 INFO [STDOUT] 2005-03-14 17:21:45,227 DEBUG cache.AglCache (TreeCache.java:2808) - commit(): removing local transaction key null

      In the log I see that on transaction <CLAUVPC:1966>:10 the _put is called for the second object before the previous transaction with id <CLAUVPC:1963>:9 is commited. Also it looks like _put for the second object in transaction <CLAUVPC:1966>:10 is called before _put for the first object in transaction <CLAUVPC:1963>:9. This indicates that the put call doesn't block the caller.

      Do I miss some settings? Is this a defect? Can anyone help me?

      thanks,
      Claudiu