11 Replies Latest reply on Nov 25, 2005 8:03 AM by belaban

    Locks removal problem with JBossCache

    skipy

      We are testing some fail-over solution and have a problem. Situation is the following.

      There are 2 servers (A and B) with cache instance on each. Server A works with cache using transactions. Server B just listens for replications. We are stopping server A (by killing it's process - this emulates server fail). After that we have some node on server B locked (something like this):

      2005-11-24 17:03:17,876 [ Thread-36] ERROR [.jboss.cache.lock.IdentityLock] () read lock for /admin/file/|apps|conf|ssl-scp.broker3.sh.test.intra-vhosts|b0|kstest122-3.com.intra could not be acquired by Thread[Thread-36,5,main] after 20000 ms
      . Locks: Read lock owners: {}
      Write lock owner: GlobalTransaction:<192.168.20.90:32917>:5824
      , lock info: write owner=GlobalTransaction:<192.168.20.90:32917>:5824
       (org.jboss.cache.lock.LockStrategyReadCommitted@bd19b9)
      


      The problem is that such locks will stay forever, thus, we can't proceed with work from the point of fail.

      I could remove such locks using, e.g., eviction mechanism. But I need to obtain lock itself in this case, to understand, if it was set by currently working cluster member, or by already dead one. BUT! All methods of org.jboss.cache.Node that concern locks are marked as Deprecated. Will be removed in JBossCache 1.3. Moreover, I can't find any replacement.

      So, the question is - how can I handle such situation? Can I configure cache to avoid such problems? If not, how can I implement smart locks removal mechanism, which will be valid in both 1.2.x and 1.3 versions (I need to remove only locks set by already dead server)?

      Regards,
      Eugene