[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
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