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 <an1...@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-boun...@lists.jboss.org >> [mailto:infinispan-dev-boun...@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 <an1...@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-boun...@lists.jboss.org >>> [mailto:infinispan-dev-boun...@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 <gal...@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@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev