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

Tue Dec 13 10:04:50 EST 2011

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.
Food for thought, I patched my version not to have them and I can tell
you it works great!

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 ?