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
>
�� ��^�����)�{(��[�8b�A�zE���&z�
y�!y�ޞm���)��r����[�� z������ٚ�X��X�����^��h�g��X���(�� ~��zw���i����l���q���z���l�X��)ߣ�ۢ� z������
