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

Galder Zamarreño (Resolved) (JIRA) jira-events at lists.jboss.org
Fri Nov 25 03:42:40 EST 2011


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

Galder Zamarreño resolved ISPN-1556.
------------------------------------

    Fix Version/s:     (was: 5.1.0.CR1)
       Resolution: Cannot Reproduce Bug


I cannot replicate this issue in master, which is very close to recently release Infinispan 5.1.0.BETA5. Gary, can you try with Infinispan 7.1.0.BETA1 (it uses Infinispan 5.1.0.BETA5) ?

Feel free to re-open if the issue is still present and attach a test case.
                
> 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

       



More information about the infinispan-issues mailing list