On Dec 14, 2011, at 2:45 PM, Mircea Markus wrote:

On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:

On 13 December 2011 13:48, Galder Zamarreño <galder@redhat.com> wrote:

On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:

Why would you avoid FORCE_WRITE_LOCK ?

Does the following make sense?

tx.begin()

cache.withFlags(FORCE_WRITE_LOCK).get(…)

tx.commit()

Yeah it's pointless to use locks if you have a single operation, but I

might want to do more operations in a single transaction.. actually

what's the point of using a transaction if I have only one operation?

WIthout transaction it is possible that the operation is only partially applied, i.e. on a subset of numOwners, resulting in inconsistent state.

Good point Mircea. You should definitely document that cos that's pretty much the sole reason to use implicit transactions, something users should know.

Nope. The reason the induced transactions(autoCommit) were added is backward compatibility: prev infinispan versions allowed mixed cache access: i.e. both transactional and non-transactional calls to a cache. Starting with 5.1,  an exception is thrown if a cache method is invoked outside of a tx's context,  unless autoCommit is set to true.