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
