[infinispan-dev] Some flags are incompatible with implicit transactions

Mircea Markus mmarkus at redhat.com
Wed Dec 14 08:37:51 EST 2011





On 13 Dec 2011, at 14:10, Galder Zamarreño <galder at 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.
Looking again at the code, the tx would be cleaned hp: if any exception is thrown for an autocommit tx, then the tx is explicitly rolledback. During the rollback the tx is removed from the 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list