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

[Gary Brown (Updated) (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Brown updated ISPN-1556:
-----------------------------

    Attachment: serverISPNTrace.log.zip


Sorry for the delay - this trace was produced with 7.1.beta1 and I had to snip the middle a bit due to the 10Mb limit, but hopefully you should still have all the info you need.
                
> 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
>         Attachments: CacheTxStackTrace.log, SampleTest.java, serverISPNTrace.log.zip
>
>
> 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