1. I see that timeout for cache.getAdvancedCache().lock(Key) is determined by LockAcquisitionTimeout that is set for the entire cache.https://docs.jboss.org/author/display/ISPN/Configuring+cache+programmatically. It makes the timeout a property of cached objects and the same across the entire cache. It seems that it would sense to consider timeout as property of operations performed on the cache objects, not the objects. So it would be up to a caller to specify the timeout, similarly to standard "tryLock(long, TimeUnit)" functionality.
2. Also it’s not clear why an innocent attempt to acquire a lock might cause transaction termination (if it exceeds the timeout). That makes it dangerous even trying to acquire a lock.
InvocationContextInterceptor.markTxForRollbackAndRethrow(InvocationContext, Throwable) line: 178
InvocationContextInterceptor.handleAll(InvocationContext, VisitableCommand) line: 144
InvocationContextInterceptor.visitLockControlCommand(TxInvocationContext, LockControlCommand) line: 94
LockControlCommand.acceptVisitor(InvocationContext, Visitor) line: 129
InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 345
CacheImpl<K,V>.lock(Collection<? extends K>, EnumSet<Flag>, ClassLoader) line: 484
CacheImpl<K,V>.lock(K...) line: 468
Is there any other Infinispan API to try acquiring a lock on a cached object with non-default timeout and without endangering the entire transaction?
On a related note. The timeout also depends on cluster size. The more nodes in the cluster, the longer each of them would wait to acquire the lock if the same task is submitted from different nodes. So again configuring lockAcquisitionTimeout as cache property doesn't seem fitting various lock usages.
Re 1. This is something we should probably add for Infinispan 6. Do you mind adding a jira in http://issues.jboss.org/browse/ISPN ?
Re 2. If the lock cannot be acquired, then you're likely to not be able to finish the transaction properly, right? What do you expect otherwise?
Re 1. Done. https://issues.jboss.org/browse/ISPN-2012
Re 2. How about trying it one more time to acquire the lock?
Let's say cache throws an exception and you'll have the same functionality if the caller doesn't handle it. But the clients will have the ability to decide by themselves if they want to re-try it or do something else. Does it make sense?