As expected, Infinispan doesn't do any remote calls in the case a transaction is read-only. That means that the calls the TxManager performs against the registered XAResource (or Synchronization) are in-memory only - and they should be very cheap. On top of that, when registered as an XAResource, ISPN signals the TM that a TX is read-only, so the commit(2nd phase) call shouldn't even be performed on any decent TM.

Also thinking about the implementation, the only way in which this optimization can be implemented is by enlisting infinispan in a transaction only during the first write (or read that has Flag.FORCE_WRITE_LOCK). But this doesn't work for the general case: if write skew check is enabled and we have the following sequence:

- tx.start()
- read(a)
- write (a) //here is where the tx is enlisted
- tx.commit()

During the commit time, the write skew check is not performed correctly as the tx is not aware of the initial read.

Given the restricted scope of this optimization and the fact that this won't bring any real performance improvements (but avoid a single in-vm cheap method call) I don't think this makes sense as it would complicate the code significantly.

On top of that, if the user doesn't want the get to be transactional, it should suspend the running transaction and resume it after the get completed.