On 13 Dec 2011, at 14: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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev