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

Tue Dec 13 12:08:28 EST 2011

On Dec 13, 2011, at 4:04 PM, Slorg1 wrote:

> Hi,
> 
> I guess I will troll a little here but it seems to me that the
> implicit transactions are the issue.
> 
> What Galder suggested does makes sense( that you would want a failure
> to put in the cache in some circumstances to have no incidence) but
> some times if too many things are telling something does not make
> sense and cannot be done right... maybe it just should not be (e.g.
> implicit transactions).
> 
> I know you feel strongly about the implicit transactions.

I don't feel strongly about them at all. If someone does it, maybe that's Mircea.

Tbh, the more I think about it, the more I dislike implicit transactions...

> Food for thought, I patched my version not to have them and I can tell
> you it works great!

Glad to know it's working fine for you :). 

Plenty going on at the moment. I'll be shortly getting around to reviewing your work… it's not forgotten!

> 
> Good luck,
> 
> Regards,
> 
> Slorg1
> 
> On Tue, Dec 13, 2011 at 09:32, Erik Salter <an1310 at hotmail.com> wrote:
>> Offhand, the only other one I use is SKIP_REMOTE_LOOKUP to avoid serializing/deserializing return values I don't care about.
>> 
>> Erik
>> 
>> -----Original Message-----
>> From: infinispan-dev-bounces at lists.jboss.org [mailto:infinispan-dev-bounces at lists.jboss.org] On Behalf Of Sanne Grinovero
>> Sent: Tuesday, December 13, 2011 9:24 AM
>> To: infinispan -Dev List
>> Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions
>> 
>> Right, it's also very useful to acquire locks on aggregates or groups
>> by locking a representative known key for the group instead of on each
>> element; very useful to guarantee consistency across disjoint elements
>> in the grid.
>> 
>> Erik, do you also SKIP_LOCKS or do other optimisations on the other operations?
>> 
>> Sanne
>> 
>> On 13 December 2011 14:12, Erik Salter <an1310 at hotmail.com> wrote:
>>> I use the pattern:
>>> 
>>> tx.begin();
>>> cache1.lock();
>>> ...
>>> tx.commit();
>>> 
>>> 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.
>>> 
>>> 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
>> 
>> _______________________________________________
>> 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
> 
> 
> 
> -- 
> Please consider the environment - do you really need to print this email ?
> 
> _______________________________________________
> 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