0 Replies Latest reply on Mar 29, 2005 12:31 AM by Jimmy Wilson

    Isolation Level of NONE Works In JBC 1.2.1?

    Jimmy Wilson Apprentice

      As mentioned in a previous post, I am using the cache in an asychronously replicated manner, and with the default isolation level of REPEATABLE_READ I get lock errors when there is moderate to heavy use of the cache.

      As suggested, I set the isolation level to NONE, and I received the following error from lots of the threads accessing the cache (even with mild to moderate use of the cache).

      java.lang.IllegalStateException: addWriter(): owner already existed
       at org.jboss.cache.lock.LockMap.addWriter(LockMap.java:112)
       at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:175)
       at org.jboss.cache.Node.acquireWriteLock(Node.java:483)
       at org.jboss.cache.Node.acquire(Node.java:440)
       at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:240)
       at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:156)
       at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
       at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
       at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
       at org.jboss.cache.interceptors.ReplicationInterceptor.replicate(ReplicationInterceptor.java:217)
       at org.jboss.cache.TreeCache._replicate(TreeCache.java:2682)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:324)
       at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
       at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220)
       at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
       at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
       at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
       at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
       at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
       at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
       at java.lang.Thread.run(Thread.java:534)
      


      Is this an issue or expected? Would a test case that presents this behavior help (it seems easy to produce in our application anyway)?

      I set the isolation level to READ_UNCOMMITTED while running the same tests that produced the above issue, and it seems promising, but I am not done testing with it yet. Is this a valid workaround for this issue?