[infinispan-issues] [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available

[Gary Brown (Commented) (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646269#comment-12646269 ] 

Gary Brown commented on ISPN-1556:
----------------------------------

Hi Galder

In 7.1.0.beta1 there is a different issue, so at the moment cannot confirm whether issue is fixed - problem is my lack of knowledge of Infinispan, so may be simple solution, but haven't been able to find an answer.

I am using the standalone-full.xml configuration, but now getting:

{code}
11:46:27,845 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Thread-1 (group:HornetQ-client-global-threads-15658959)) ISPN000136: Execution error: org.infinispan.CacheException: Explicit locking is not allowed with optimistic caches!
	at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitLockControlCommand(OptimisticLockingInterceptor.java:163) [infinispan-core-5.1.0.BETA5.jar:]
	at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129) [infinispan-core-5.1.0.BETA5.jar:]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119) [infinispan-core-5.1.0.BETA5.jar:]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133) [infinispan-core-5.1.0.BETA5.jar:]
...
{code}

which then results in further exceptions of the type:

{code}
11:46:27,879 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Thread-1 (group:HornetQ-client-global-threads-15658959)) ISPN000136: Execution error: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffffc0a80175:3c514c1:4ed4c603:111 status: ActionStatus.ABORT_ONLY > is not in a valid state to be invoking cache operations on.
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:234) [infinispan-core-5.1.0.BETA5.jar:]
	at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:197) [infinispan-core-5.1.0.BETA5.jar:]
	at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:191) [infinispan-core-5.1.0.BETA5.jar:]
	at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:187) [infinispan-core-5.1.0.BETA5.jar:]
...
{code}

I tried changing the locking isolation, but had no effect. So this appears to be a change in behaviour between AS7.1 alpha2 and beta1, but not sure how to configure the cache so not optimistic, as according to docs there is no explicit way to set this: https://docs.jboss.org/author/pages/viewpage.action?pageId=5832814 (I guess because it is implicit).

Any help appreciated.

                
> Ability to test and acquire lock if available, without aborting the txn if not available
> ----------------------------------------------------------------------------------------
>
>                 Key: ISPN-1556
>                 URL: https://issues.jboss.org/browse/ISPN-1556
>             Project: Infinispan
>          Issue Type: Feature Request
>    Affects Versions: 5.1.0.BETA2
>         Environment: AS7.1.0.alpha2
>            Reporter: Gary Brown
>            Assignee: Galder Zamarreño
>
> I have a system that performs a large number of tasks in a single transaction for efficiency. Some of those tasks access infinispan caches.
> I found that occasionally I have been getting lock timeouts for the default 15 second period.
> Lock contention is not a problem - but the impact of failing to obtain the lock results in the whole transaction being aborted, which aborts the work also carried out for potentially a large number of other tasks, resulting in all of the work being retried.
> I was wondering if it would be possible to provide an alternative lock implementation the AdvancedCache that allowed a client app to test whether the lock was available and acquire it - returning 'true', but if the lock was not available, simply returning false, allowing the client code to make a decision about how to proceed.
> In my case, I could then add the specific task to a retry queue, and move onto the next task, committing all of the work that had been successfully completed for the other tasks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira