We try to use infinispan as a remote cache with a read lock. The clients are making a read with a "put" in order to acquire a lock on the key, like described infinispan documentation in the section pessimistic transactional cache "When cache.put(k1,v1) returns, k1 is locked and no other transaction running anywhere in the cluster can write to it. Reading k1 is still possible. The lock on k1 is released when the transaction completes (commits or rollbacks). so the scenario :
transactionManager.begin();
// read with put to acquire write lock
String value = getRemoteCache().get(key);
getRemoteCache().put(key, value);
// do smthing with the value
getRemoteCache().put(key, newValue);
transactionManager.commit();
the remote cache is configured as transactional with pessimistic locking :
<local-cache name="default"> <locking isolation="REPEATABLE_READ" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
<transaction mode="NON_XA" locking="PESSIMISTIC"/>
</local-cache>
and the clients are accessing the remoteCacheManager as HOTROD client with the configuration:
ConfigurationBuilder builder = new ConfigurationBuilder();
// add more configurations ?
builder.transaction().transactionManagerLookup(GenericTransactionManagerLookup.getInstance());
builder.transaction().transactionMode(TransactionMode.NON_XA);
builder.addServer().host(readServerHostConfiguration()).port(readServerPortConfiguration());
return new RemoteCacheManager(builder.build(), true);
Despite that the clients could "read with put" one value simultaneously, Concurent clients are not getting the exception when putting the value when reading it, but only later by commiting the transction. Is that the expected bahavior ?
Yes, it is.
As described in the docs (Hot Rod Transaction) the transaction running on the client has optimistic semantics. The locks will be acquired only during commit.
The pessimistic locking transactions are only valid in embedded mode.