Tom, You're very wrong. Option B with "Instance Per Transaction" is a very good viable solution for those that allow Read-Committed-like access to entity beans and have synchronization problems with their entity beans (deadlock). I have a few customers using this option. Please do not mislead everybody here.
And, I really disagree that the solution is "not standard". Stop misleading everybody. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tom > M. Yeh > Sent: Thursday, August 01, 2002 10:13 PM > To: Jboss-Development > Subject: RE: [JBoss-dev] Please support Option B > > > Jim, > > My example is a bit misleading. My point is the database already > does a good locking mechanism, and there is no reason to > implement one in EJB container. However, to get the best from the > database, we need something like Option B: one instance per > transaction, ejbLoad when first hit in a transaction, and no > passivation after transaction complete. It is actually the > simplest form if some one wants to implement a ACID cache for > accessing database from scratching. > > MethodOnlyEJBLock and read-only flags are solution, but it, > besides not standard, takes too much effort for both container > and bean developers. After all, solving the deadlock issues at > database level for a sophisticated system is already a challenge. > > Tom > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of James > > Cook > > Sent: Friday, August 02, 2002 8:20 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Please support Option B > > > > > > Options A, B, C or D don't have anything to do with this deadlock > > scenario that you refer to. I am assuming you are talking about > > an app server deadlock since you don't mention a specific > > database deadlock condition. > > > > Most "advanced" servers (WebLogic, WebSphere, etc.) allow the > > same Bean instance (same Home, same PK) to exist in multiple > > transactions. Originally, Weblogic chose the more pessimistic > > approach, that jBoss has enabled by default, but they default to > > the multi-instance approach back in WL6. This pushes the > > responsibility on the developer to ensure that the database is > > ACID, but most developers of scalable systems will do this > > anyway. If not simply to support the multi-container scenario you > > allude to. > > > > 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 > > > +, 隊X'uNggr剞 zH^j m ( > n, zZ) x%Inퟝ, zZ) X y + zmض b q +-떳b ~n, ׯzZ) > ------------------------------------------------------- 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
