On 14 Dec 2011, at 15:55, Galder Zamarreño wrote:
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(a)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.