Re: [infinispan-dev] Some flags are incompatible with implicit transactions
On Dec 13, 2011, at 3:00 PM, 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..
More than one cache operations in a single tx requires external or explicit tx management.
Remember that here I'm refering to implicit transactions where each cache operation is
surrounded by a tx:
tx.begin();
cache.<put your fav op here>
tx.commit; / tx.rollbacl();
actually
what's the point of using a transaction if I have only one operation?
That's what implicit transactions or autoCommit=true (if no external tx is on) gives
you… ;)
tx.begin()
int counter = (Integer) cache.withFlags(FORCE_WRITE_LOCK).get(…)
counter++;
cache.put(k, counter);
tx.commit()
That's explicit tx management, outside the scope of this email.
> It doesn't in my view. You force a write lock to then to something within a
transaction with the knowledge that the key is locked.
>
>> Will I still be able to use an
>> explicit cache.lock() operation? Acquiring a pessimistic lock might be
>> an important functionality in some use cases.
>
> That's another interesting one, what's the point of doing:
>
> tx.begin()
> cache.lock()
> tx.commit()
>
> I don't see lock() being compatible with implicit tx.
Same as above..
>
>>
>> About FAIL_SILENT.. I'm not sure about the use case, but I would
>> expect it to just avoid logging errors and to swallow eventual
>> exceptions ?
>
> Javadoc:
> * <p>Swallows any exceptions, logging them instead at a low log level. Will
prevent a failing operation from
> * affecting any ongoing JTA transactions as well.</p>
>
> I see not affecting the on going JTA transaction as the bigger motivator for using it
rather than just avoiding showing the errors. Do you have any particular use case where
the following makes sense?
>
> tx.begin();
> cache.withFlags(FAIL_SILENT).put(k, v);
> tx.commit();
Don't ask me, but whoever invented the flag .. ;) If there are good
use cases out of transaction, it might make sense in transaction as
well.
The primary use case for FAIL_SILENT is putForExternalRead() in my view and that happens,
for the moment at least, within a transaction.
Even if we end up requiring a PFER to run outside of a transation, we won't add
implicit transactions or autoCommit cos that'd be useless.
Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache