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?