Re: [jbosscache-dev] Problems with node locking semanticsinJBC1.4.1.GA

But thinking through it again, not any riskier than the isolation level set in the config. Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat -----Original Message----- From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev- bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno Sent: 30 January 2007 01:07 To: Brian Stansberry; jbosscache-dev(a)lists.jboss.org Cc: Max Andersen; Steve Ebersole; Bill Decoste; Carlo de Wolf Subject: RE: [jbosscache-dev] Problems with node locking semanticsinJBC1.4.1.GA Actually, I had a case this morning asking about this. The customer wanted to could control what the locking type to acquire. I did comment against it due to possible misuse that could end up in data corruption. I can see however the possible use cases, but the risks are high as well IMO. Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat -----Original Message----- From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev- bounces(a)lists.jboss.org] On Behalf Of Brian Stansberry Sent: 29 January 2007 21:49 To: jbosscache-dev(a)lists.jboss.org Cc: Max Andersen; Carlo de Wolf; Bill Decoste; Steve Ebersole Subject: FW: [jbosscache-dev] Problems with node locking semantics inJBC1.4.1.GA Accidentally didn't include the rest of the distribution on this response. Brian Stansberry wrote: > I like your thinking on that. Haven't looked at the details, but the > concept makes a lot of sense. > > Was chatting with Manik on this this AM, and here's what we came up > with as an action plan. This is somewhat governed by very tight > release schedules for 1.4.x, along with a desire to not change the > Node interfaces in the 1.x series. > > For both Branch_1_4_0 and HEAD: > > 1) I'll add cache configuration attribute > LockParentForChildInsertRemove. 2) I'll change PLI to use that to > decide whether to acquire a WL or RL. 3) Manik will look into > changing optimistic locking uses that to decide whether > addition/removal of a child causes an increase in the nodes version. > (Not sure if that will be in 1.4.x). > > For HEAD only: > > 4) I'll add a JIRA to make this behavior changeable per node. I'll > open a forum thread for the JIRA and without objection, Elias, I'll > paste your idea as the first post. > > - Brian > > Elias Ross wrote: >> --- Brian Stansberry <brian.stansberry(a)jboss.com&gt; wrote: >> >>> Even further, that could be treated as a cache wide default, >>> used to >>> set a flag on each node. The PessimisticLockInterceptor could check >>> that flag to decide whether to get the WL. What's nice about that >>> is the cache wide default could be true, but for certain nodes the >>> application could set it to false. E.g the root node for a webapp >>> under which sessions are stored, root node for an SFSB or entity >>> under which instances are stored, PojoCache's _JBossInternal_ node >>> etc. Simpler alternative to lock striping on the child map. >> >> The Node itself keeps a NodeLock instance. Perhaps the specific >> choice of lock (read-write) could be delegated to the NodeLock >> itself? >> >> In particular, for the method: >> >> boolean acquire(Object caller, long timeout, NodeLock.LockType >> lock_type); >> >> it might make sense to replace the LockType parameter with an >> operation parameter? E.g. >> >> boolean acquire(Object caller, long timeout, NodeLock.Operation op); >> >> Then there needs to be some way to set the particular strategy per >> node. It's theoretically possible, but there needs to be a standard >> API to expose this. E.g. >> >> void setLockStrategy( ... ); >> >> With this in mind, the NodeLock interface should get revisited in >> time for 2.0. >> >> >> >> ______________________________________________________________ >> ______________________ Get your own web address. >> Have a HUGE year through Yahoo! Small Business. >> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev