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

[Galder Zamarreño]

On Dec 13, 2011, at 3:12 PM, Erik Salter wrote:

> I use the pattern:
> 
> tx.begin();
> cache1.lock();
> ...
> tx.commit();

Right, but that pattern is not implicit tx where each cache operation is surrounded internally by a transaction.

You are doing explicit or external tx management which is not what this email is asking.

> 
> There are other caches involved in the transaction, but cache1 doesn't
> actually put any data.  It's just there so I don't have to acquire 8-13
> explicit locks on the other caches.  Improved throughput in my application.
> 
> I also use this pattern:
> 
> tx.begin();
> boolean result = cache.withFlags(FAIL_SILENT).lock(k); 
> // Something interesting..
> tx.commit();
> 
> ...Same reason.  I have a pool of keys and if one fails, I go to the next
> one.  Again, keeps me from needing to acquire a bunch of explicit locks.

Again, same story. You are doing explicit tx management. Not in the scope of this email.

> 
> Erik
> 
> -----Original Message-----
> From: infinispan-dev-bounces at lists.jboss.org
> [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Galder
> Zamarreño
> Sent: Tuesday, December 13, 2011 8:49 AM
> To: infinispan -Dev List
> Subject: 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 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.
>>> 
>>> 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
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> 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
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache