[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=12645192#comment-12645192 ] 

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

Sorry just found ISPN-664 which suggests atleast part of this functionality is there - I must have consulted an older version of the API before.

However in my experiments I had tried FAIL_SILENT flag, but the xa transaction was aborted.

I'll double check again, and close the issue if works - otherwise I guess it should be a bug rather than feature request.
 
                
> 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: Manik Surtani
>
> 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