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

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(a)lists.jboss.org [mailto:infinispan-dev-bounces@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(a)hotmail.com&gt; 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(a)lists.jboss.org > [mailto:infinispan-dev-bounces@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(a)jboss.org&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev