9 Replies Latest reply on Sep 22, 2008 11:55 AM by Manik Surtani

    Optimistic locking not working with JDBCCacheLoader configur

    Ken Ringdahl Newbie

      I'm unable to get optimistic locking to work with the JDBCCacheLoader when I use a datasource. When I supply the DS configuration to JBC directly, it works just fine. I have included the exception / stack trace I get below. I'm using 2.2.0.GA. is this a known issue? Could this be a config issue? The onyl thing I change is my cache loader config to get this working outside of the DS supplied by JBoss AS. here is the cache loader config that works:

      <attribute name="CacheLoaderConfig">
       <config>
       <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
       <passivation>false</passivation>
       <preload>/</preload>
       <shared>true</shared>
      
       <!-- we can now have multiple cache loaders, which get chained -->
       <cacheloader>
       <class>org.jboss.cache.loader.JDBCCacheLoader</class>
      
       <properties>
       cache.jdbc.table.name=dht
       cache.jdbc.table.primarykey=dht_pk
       cache.jdbc.table.create=false
       cache.jdbc.table.drop=false
       cache.jdbc.fqn.column=fqn
       cache.jdbc.fqn.type=varchar(255)
       cache.jdbc.node.column=value
       cache.jdbc.node.type=BYTEA
       cache.jdbc.parent.column=parent_fqn
       cache.jdbc.driver=org.postgresql.Driver
       cache.jdbc.url=jdbc:postgresql://localhost:5432/fabric?useUnicode=true&amp;characterEncoding=utf-8
       cache.jdbc.user=postgres
       cache.jdbc.password=postgres
       cache.jdbc.sql-concat=1||2
       </properties>
      
       <!-- whether the cache loader writes are asynchronous -->
       <async>false</async>
      
       <!-- only one cache loader in the chain may set fetchPersistentState to true.
       An exception is thrown if more than one cache loader sets this to true. -->
       <fetchPersistentState>false</fetchPersistentState>
      
       <!-- determines whether this cache loader ignores writes - defaults to false. -->
       <ignoreModifications>false</ignoreModifications>
      
       <purgeOnStartup>false</purgeOnStartup>
       </cacheloader>
      
       </config>
       </attribute>
      


      Here is the cache loader config that does not work:

      <attribute name="CacheLoaderConfig">
       <config>
       <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
       <passivation>false</passivation>
       <preload>/</preload>
       <shared>true</shared>
      
       <!-- we can now have multiple cache loaders, which get chained -->
       <cacheloader>
       <class>org.jboss.cache.loader.JDBCCacheLoader</class>
      
       <properties>
       cache.jdbc.table.name=dht
       cache.jdbc.table.primarykey=dht_pk
       cache.jdbc.table.create=false
       cache.jdbc.table.drop=false
       cache.jdbc.fqn.column=fqn
       cache.jdbc.fqn.type=varchar(255)
       cache.jdbc.node.column=value
       cache.jdbc.node.type=BYTEA
       cache.jdbc.parent.column=parent_fqn
       cache.jdbc.datasource=java:/jdbc/FabricDS
       cache.jdbc.sql-concat=1||2
       </properties>
      
       <!-- whether the cache loader writes are asynchronous -->
       <async>false</async>
      
       <!-- only one cache loader in the chain may set fetchPersistentState to true.
       An exception is thrown if more than one cache loader sets this to true. -->
       <fetchPersistentState>false</fetchPersistentState>
      
       <!-- determines whether this cache loader ignores writes - defaults to false. -->
       <ignoreModifications>false</ignoreModifications>
      
       <purgeOnStartup>false</purgeOnStartup>
       </cacheloader>
      
       </config>
       </attribute>
      


      Note that the only difference is in the properties.

        • 1. Re: Optimistic locking not working with JDBCCacheLoader conf
          Ken Ringdahl Newbie

          I meant to also include the log and exception. Here it is:

          2008-09-06 21:39:29,915 DEBUG [org.jboss.cache.interceptors.OptimisticLockingInterceptor] Locking nodes in transaction workspace for GlobalTransaction GlobalTransaction:
          <172.30.255.38:57328>:2
          2008-09-06 21:39:29,916 DEBUG [org.jboss.cache.interceptors.OptimisticValidatorInterceptor] Validating 111 nodes.
          2008-09-06 21:39:29,917 DEBUG [org.jboss.cache.interceptors.OptimisticValidatorInterceptor] Successfully validated nodes
          2008-09-06 21:39:29,917 DEBUG [org.jboss.cache.interceptors.OptimisticReplicationInterceptor] (172.30.255.38:57328):not broadcasting prepare as members are [172.30.255.3
          8:57328]
          2008-09-06 21:39:29,979 DEBUG [org.jboss.cache.interceptors.OptimisticTxInterceptor] Running commit phase. One phase? false
          2008-09-06 21:39:29,980 DEBUG [org.jboss.cache.interceptors.OptimisticValidatorInterceptor] Commiting successfully validated changes for GlobalTransaction GlobalTransact
          ion:<172.30.255.38:57328>:2
          2008-09-06 21:39:29,981 DEBUG [org.jboss.cache.loader.JDBCCacheLoader] executing sql: select value from dht where fqn=? (/__JBossInternal__/dht/element/inventory/list/_I
          D_/3j011-ht193x-fkt239cl-1-fkt23wrd-p)
          2008-09-06 21:39:29,985 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true
          2008-09-06 21:39:29,985 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false
          2008-09-06 21:39:29,985 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
          2008-09-06 21:39:29,985 ERROR [org.jboss.cache.loader.JDBCCacheLoader] Failed to load node for fqn /__JBossInternal__/dht/element/inventory/list/_ID_/3j011-ht193x-fkt239
          cl-1-fkt23wrd-p
          org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000101:8914:48c33ec2:31 status: ActionStatus.COMMITTED >; - nested
           throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000101:8914:48c33ec2:31 status: ActionStatus.COMMITTED
           >)
           at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94)
           at org.jboss.cache.loader.ManagedConnectionFactory.getConnection(ManagedConnectionFactory.java:74)
           at org.jboss.cache.loader.AdjListJDBCCacheLoader.loadNode(AdjListJDBCCacheLoader.java:359)
           at org.jboss.cache.loader.JDBCCacheLoader._put(JDBCCacheLoader.java:214)
           at org.jboss.cache.loader.JDBCCacheLoader.put(JDBCCacheLoader.java:76)
           at org.jboss.cache.interceptors.CacheStoreInterceptor.storeInternalState(CacheStoreInterceptor.java:297)
           at org.jboss.cache.interceptors.CacheStoreInterceptor.handleCommitCommand(CacheStoreInterceptor.java:136)
           at org.jboss.cache.interceptors.base.SkipCheckChainedInterceptor.visitCommitCommand(SkipCheckChainedInterceptor.java:319)
           at org.jboss.cache.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:28)
           at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
           at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:157)
           at org.jboss.cache.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:129)
           at org.jboss.cache.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:28)
           at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
           at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.visitCommitCommand(OptimisticReplicationInterceptor.java:111)
           at org.jboss.cache.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:28)
           at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
           at org.jboss.cache.interceptors.NotificationInterceptor.visitCommitCommand(NotificationInterceptor.java:38)
           at org.jboss.cache.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:28)
           at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
           at org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterceptor.java:541)
           at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:574)
           at org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:973)
           at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.afterCompletion(TxInterceptor.java:1146)
           at org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:71)
           at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)
           at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:340)
           at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
           at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
           at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
           at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
           at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
           at com.desktone.server.accessFabric.aspect.FabricTxnInterceptor.invoke(FabricTxnInterceptor.java:64)
           at com.desktone.server.accessFabric.JoinPoint_bootstrap7836980175927639016_1.invokeNext(JoinPoint_bootstrap7836980175927639016_1.java)
           at com.desktone.server.accessFabric.JoinPoint_bootstrap7836980175927639016_1.invokeJoinpoint(JoinPoint_bootstrap7836980175927639016_1.java)
           at com.desktone.server.accessFabric.FabricAccessImpl$FabricAccessImplAdvisor.bootstrap7836980175927639016(FabricAccessImpl$FabricAccessImplAdvisor.java)
           at com.desktone.server.accessFabric.FabricAccessImpl.bootstrap(FabricAccessImpl.java)
           at com.desktone.server.accessFabric.service.FabricAccessService.startService(FabricAccessService.java:69)
           at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
           at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
           at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:585)
           at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
           at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
           at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
           at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
           at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
           at $Proxy0.start(Unknown Source)
           at org.jboss.system.ServiceController.start(ServiceController.java:417)
           at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:585)
           at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
           at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
           at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
           at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
           at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
           at $Proxy4.start(Unknown Source)
           at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
           at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
           at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
           at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
           at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
           at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:585)
           at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
           at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
           at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
           at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
           at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
           at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
           at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
           at $Proxy9.deploy(Unknown Source)
           at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
           at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
           at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
           at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
           at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
           at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
           at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:585)
           at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
           at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
           at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
           at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
           at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
           at $Proxy0.start(Unknown Source)
           at org.jboss.system.ServiceController.start(ServiceController.java:417)
           at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
           at java.lang.reflect.Method.invoke(Method.java:585)
           at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
           at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
           at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
           at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
           at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
           at $Proxy4.start(Unknown Source)
           at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
           at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
           at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
           at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
           at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
           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:585)
           at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
           at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
           at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
           at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
           at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
           at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
           at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
           at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
           at $Proxy5.deploy(Unknown Source)
           at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
           at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
           at org.jboss.Main.boot(Main.java:200)
           at org.jboss.Main$1.run(Main.java:508)
           at java.lang.Thread.run(Thread.java:595)
          Caused by: javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000101:8914:48c33ec2:31 status: ActionStatus.COMMITTED >
           at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:304)
           at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
           at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
           at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
           ... 129 more
          2008-09-06 21:39:29,993 WARN [org.jboss.cache.interceptors.OptimisticTxInterceptor] Commit failed. Clearing stale locks.
          
          


          • 2. Re: Optimistic locking not working with JDBCCacheLoader conf
            Ken Ringdahl Newbie

            One other questions related to optimistic locking...is there anything I can do to switch an existing cache configured with pessimistic locking to optimistic locking? For existing caches, it appears that it can load the objects because they do not have the appropriate data versioning. Anything that can be done outside of reading the entire cache and writing it out again in optimistic mode?

            • 3. Re: Optimistic locking not working with JDBCCacheLoader conf
              Mircea Markus Master

              this is a bug in code.
              I've created https://jira.jboss.org/jira/browse/JBCACHE-1408 for this.

              One other questions related to optimistic locking...is there anything I can do to switch an existing cache configured with pessimistic locking to optimistic locking? For existing caches, it appears that it can load the objects because they do not have the appropriate data versioning. Anything that can be done outside of reading the entire cache and writing it out again in optimistic mode?

              No way of updating the database directly, as the version is stored binary together with other data map.

              • 4. Re: Optimistic locking not working with JDBCCacheLoader conf
                Manik Surtani Master

                 

                "kringdahl" wrote:
                One other questions related to optimistic locking...is there anything I can do to switch an existing cache configured with pessimistic locking to optimistic locking? For existing caches, it appears that it can load the objects because they do not have the appropriate data versioning. Anything that can be done outside of reading the entire cache and writing it out again in optimistic mode?


                So far no one has asked for anything of the sort, but I can see how it could be a useful thing. I would recommend writing a conversion app right now, that would start 2 cache instances (one in OL and one in PL) and read from one and write to the other.

                • 5. Re: Optimistic locking not working with JDBCCacheLoader conf
                  Ken Ringdahl Newbie

                  Well, we have run into some other problems with Optimistic locking which caused us to have pull back. We're really waiting for MVCC regardless. But, we did need to migrate our cache anyway because of the PojoInstance change from PojoCache 2.1 to 2.2. And we did do that by pulling each cache object out, using copy constructors to strip the object clean, and reinserting.

                  • 6. Re: Optimistic locking not working with JDBCCacheLoader conf
                    Manik Surtani Master

                    Have you tried MVCC with 3.0.0.BETA1? Feedback would be very useful. :)

                    • 7. Re: Optimistic locking not working with JDBCCacheLoader conf
                      Ken Ringdahl Newbie

                      We're ready to provide feedback. The ETA on integrating into our development branch is < 2 weeks.

                      • 8. Re: Optimistic locking not working with JDBCCacheLoader conf
                        Manik Surtani Master

                        Regarding JBCACHE-1408, can you confirm that this only happens when you use a data source for your JDBC connection and not if you use your own conn pooling or a direct JDBC URL?

                        • 9. Re: Optimistic locking not working with JDBCCacheLoader conf
                          Manik Surtani Master

                          My prev comment was about fleshing out the workaround for the JIRA better.

                          I have a fix in SVN (the 2.2.X branch as well as trunk) if you care to try it out. Since you are on 2.2.0.GA, I would recommend building 2.2.X and giving it a go instead.