yes, commit b is a requirement, and Instantce Per Transaction is available in 2.4.6. THe interceptors needed are
EntityMultiInstanceInterceptor EntityMultiInstanceSynchronizationInterceptor and MethodOnlyEJBLock. Take a look at standardjboss.xml in 3.0 and you'll be able to apply it. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of James > Cook > Sent: Sunday, August 04, 2002 1:42 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Please support Option B (response to Jim Cook) > > > I am deployed on jBoss 2.4.6, and I changed to MethodOnlyEJBLock > to prevent some spurious ApplicationDeadlockExceptions that > occur. Is it a requirement on the 2.4 version of the server to > use commit option B as well? > > jim > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of Bill Burke > > Sent: Friday, August 02, 2002 11:30 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Please support Option B (response to > > Jim Cook) > > > > > > Jim > > > > Do not use MethodOnlyEJBLock on its own. In JBoss 3.0.1 and > > higher there is an additional container configuration you can > > use that creates an Instance per transaction for each entity > > bean. The side-effects, you must use Commit-option 'B' and > > you do not get serialized access to your entity beans. > > (analogy is Read-committed behaviour instead of serialized). > > > > i.e. > > > > <jboss> > > <enterprise-beans> > > <entity> > > <ejb-name>MyCMP2Bean</ejb-name> > > <jndi-name>MyCMP2</jndi-name> > > <configuration-name>Instance Per Transaction CMP > > 2.x EntityBean</configuration-name> > > </entity> > > <entity> > > <ejb-name>MyBMPBean</ejb-name> > > <jndi-name>MyBMP</jndi-name> > > <configuration-name>Instance Per Transaction BMP > > EntityBean</configuration-name> > > </entity> > > > > </enterprise-beans> > > </jboss> > > > > > > Also, in 3.0, for the default pessimistic locking, you can > > now define methods as read-only(thanks to Peter Murray). > > Meaning, invoking on read-only methods will not lock the > > entity bean into the transaction. To use this: > > > > <jboss> > > <enterprise-beans> > > <entity> > > <ejb-name>nextgen.EnterpriseEntity</ejb-name> > > <jndi-name>nextgen.EnterpriseEntity</jndi-name> > > <method-attributes> > > <method> > > <method-name>get*</method-name> > > <read-only>true</read-only> > > </method> > > <method> > > <method-name>anotherReadOnlyMethod</method-name> > > <read-only>true</read-only> > > </method> > > </method-attributes> > > </entity> > > </enterprise-beans> > > </jboss> > > > > I have written a document on this stuff in the soon-to-be > > published 3.0 for-pay documentation. Email me if you have > > any further questions. > > > > Bill > > > > > > > But back to EB locking, jBoss supports MethodOnlyEJBLock as a > > > configuration option. I'm not absolutely sure, but isn't that the > > > same thing as the opptomistic locking that WL and other > > servers support? > > > > > > jim > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]] On > > > > Behalf Of Tom M. Yeh > > > > Sent: Thursday, August 01, 2002 8:04 AM > > > > To: Jboss-Development > > > > Subject: RE: [JBoss-dev] Please support Option B > > > > > > > > > > > > So, why Option B? > > > > > > > > Let us assume you have two beans, A and B. One transaction > > > > reads A and then B, while the other transaction reads B then > > > > A. If option A is used, a dead lock occurs even though both > > > > transactions won't modify A or B (this is OK if we access > > > > database directly without using EJB). > > > > > > > > So some says let us alter EJB spec a bit by allowing multiple > > > > bean instances (i.e., each transaction has an independent > > > > instance) for option A. But, if one transaction modifies A, > > > > how shall the other transactions know and react? Some says > > > > let developer specify which methods are read-only. If we do > > > > it correctly, we just redo what the database already do > > > > (read/update/exclusive locking, isolation level...). And, how > > > > about clustering? > > > > > > > > Some suggests to use stored procedure to trigger and > > > > invalidate corresponding instances. Beside the question of > > > > when to invalidate, it is hard to know what instances are > > > > affected by simply looking at a database table -- you need > > > > metainfo about how objects are mapped to tables and try to > > > > map tables back to objects. Even you could, how about > > > > clustering? One VM notifies another? > > > > > > > > If we have Option B, then we could let database do what they > > > > are good at. We just make sure the cached instances is > > > > consistent with records in database. How? Optimistic lock for > > > > one -- versioning or timestamp is good enough. It can be done > > > > easily when ejbLoad is called -- which is demanded for option > > > > B. However, in the current implementation, all instances are > > > > trashed after a transaction complete, no matter option B or > > > > C. Thus, optimistic lock is useless and we have to reload > > > > instances when a new transaction starts. > > > > > > > > After all, loading and comparing a timestamp is much cheaper > > > > than loading the whole instance, because an instance usually > > > > has multiple relations to other instances. > > > > > > > > > Commit option A and when the row changes in the > > database a stored > > > > > procedure notifies the server that the data in cache is no > > > > longer valid. > > > > > > > > > > -dain > > > > > > > > > > Ignacio Coloma wrote: > > > > > > > > > >> What is that "notifications" on A scheme marc is talking about? > > > > >> > > > > >> Dan Christopherson wrote: > > > > >> > > > > >>> OK, so it's more a matter of allowing multiple bean > > > > instances. Once > > > > >>> that's there, B or C doesn't really matter - the > > extra overhead > > > > >>> implied by C is noise compared to the database read > > > > (which you need > > > > >>> either way). > > > > >>> Of course, anybody that can use option A should. > > > > >>> > > > > >>> -danch > > > > >>> > > > > >>> Bill Burke wrote: > > > > >>> > > > > >>>> Yes, Tom, be more specific. I know you're smarter than that. > > > > >>>> You're probably talking about the "Instance per Transaction" > > > > >>>> locking scheme. This works fine with commit-option 'B'. > > > > Yes, it > > > > >>>> is not totally optimized, but is > > > > >>>> does pool dead instances. > > > > >>>> > > > > >>>> Bill > > > > >>>> > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: [EMAIL PROTECTED] > > > > >>>>> > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > >>>>> Dan > > > > >>>>> Christopherson > > > > >>>>> Sent: Friday, July 19, 2002 10:08 AM > > > > >>>>> To: [EMAIL PROTECTED] > > > > >>>>> Subject: Re: [JBoss-dev] Please support Option B > > > > >>>>> > > > > >>>>> > > > > >>>>> Whahuh? JBoss doesn't support option B? > > > > >>>>> > > > > >>>>> Tom M. Yeh wrote: > > > > >>>>> > > > > >>>>>> Dear All, > > > > >>>>>> > > > > >>>>>> According to the CSIRO report > > > > >>>>>> > > > > >>>>> (http://www.cmis.csiro.au/adsat/jboss.htm), JBoss is doing > > > > >>>>> well > > > > >>>>> with Stateless session beans. It implies reflection, by > > > > comparing > > > > >>>>> to static compiled codes, doesn't affect the > > performance much, > > > > >>>>> while it has great architectural advantages such as > > pluggable > > > > >>>>> interceptors. > > > > >>>>> > > > > >>>>>> However, entity beans is not the case. One of the reason, I > > > > >>>>>> > > > > >>>>> think, is this report uses Option B, which JBoss > > > > doesn't support > > > > >>>>> (and uses Option C instead). In other words, all beans > > > > are trashed > > > > >>>>> after a transaction is completed. It then > > introduces a lot of > > > > >>>>> overhead since every transaction has to reload all > > > > beans involved > > > > >>>>> from database (and you know accessing database kills the > > > > >>>>> performance). > > > > >>>>> > > > > >>>>>> After examining the codes and a few talks with > > Bill, I don't > > > > >>>>>> > > > > >>>>> think I am capable to modify the codes to support Option B. > > > > >>>>> Any > > > > >>>>> volunteer is willing to do that? > > > > >>>>> > > > > >>>>>> Thanks and Regards, > > > > >>>>>> Tom > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> ------------------------------------------------------- > > > > >>>>> This sf.net email is sponsored by:ThinkGeek > > > > >>>>> Welcome to geek heaven. > > > > >>>>> http://thinkgeek.com/sf > > > > >>>>> _______________________________________________ > > > > >>>>> Jboss-development mailing list > > > > >>>>> [EMAIL PROTECTED] > > > > >>>>> > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> ------------------------------------------------------- > > > > >>>> This sf.net email is sponsored by:ThinkGeek > > > > >>>> Welcome to geek heaven. > > > > >>>> http://thinkgeek.com/sf > > > > >>>> _______________________________________________ > > > > >>>> Jboss-development mailing list > > > > >>>> [EMAIL PROTECTED] > > > > >>>> > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> ------------------------------------------------------- > > > > >>> This sf.net email is sponsored by:ThinkGeek > > > > >>> Welcome to geek heaven. > > > > >>> http://thinkgeek.com/sf > > > > >>> _______________________________________________ > > > > >>> Jboss-development mailing list > > > > >>> [EMAIL PROTECTED] > > > > >>> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> ------------------------------------------------------- > > > > >> This sf.net email is sponsored by:ThinkGeek > > > > >> Welcome to geek heaven. > > > > >> http://thinkgeek.com/sf > > > > >> _______________________________________________ > > > > >> Jboss-development mailing list > > > > >> [EMAIL PROTECTED] > > > > >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > >N±µŠ²²u†Y¢¢’½¶þžz›%±z™™ŠŠnu–zŠ²q®z¶þ¶º~zþ¶Š±z™ > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
