Re: [infinispan-dev] Some flags are incompatible with implicit transactions
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()
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.
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();
Sanne
On 13 December 2011 12:10, Galder Zamarreño <galder(a)jboss.org> wrote:
> Hi all,
>
> Re: https://issues.jboss.org/browse/ISPN-1556
> Re: https://github.com/infinispan/infinispan/pull/719/files#r288994
>
> The fix I suggest works well with explicit transactions, but if we leave this as is,
implicit txs might leak transactions. The reason is because if we allow a put with
FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor
removed from tx table.
>
> But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of
FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that
there's a bigger, external, transaction within which this operation is called.
>
> And it's not just FAIL_SILENT, there're other flags do not make sense with
implicit transactions, such as FORCE_WRITE_LOCK:
>
> /**
> * Forces a write lock, even if the invocation is a read operation. Useful when
reading an entry to later update it
> * within the same transaction, and is analogous in behavior and use case to a
<tt>select ... for update ... </tt>
> * SQL statement.
> */
>
> So, I think my fix is right here, but what we really need is it's a way to stop
people from using certain flags with implicit transactions. Here's my (quickly
thought) list:
>
> FORCE_WRITE_LOCK
> FAIL_SILENTLY
> PUT_FOR_EXTERNAL_READ
>
> Any others?
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
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