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

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

Updated the code to create the cache manager with pessimistic lock mode:

{code}
Configuration config = manager.getDefaultConfiguration().clone().fluent()
		.locking()
			.concurrencyLevel(10000).isolationLevel(IsolationLevel.REPEATABLE_READ)
			.lockAcquisitionTimeout(12000L).useLockStriping(false).writeSkewCheck(true)
		.transaction()
			.lockingMode(LockingMode.PESSIMISTIC)
			.recovery()
			.transactionManagerLookup(new GenericTransactionManagerLookup())
		.build();
			
String newCacheName = "conversationDetails";
manager.defineConfiguration(newCacheName, config);
			
org.infinispan.Cache<ConversationId,ConversationDetails> conversationDetails=
		manager.getCache("conversationDetails");
			
_conversationDetails = conversationDetails.getAdvancedCache()
		.withFlags(Flag.FAIL_SILENTLY, Flag.ZERO_LOCK_ACQUISITION_TIMEOUT);
{code}

Now able to explicitly lock and get result as to whether lock succeeded - but if false, then subsequent get() is still failing with same transaction exception. Is this cache configuration ok?

                
> 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