Yes it is normal this is the default.
However you can change the default by bringing up the DeployerTool and doing
the following:
- Click on the Optimizations leaf in the tree for the bean in question.
- Uncheck the Updates at end of transaction.

This will change the XML in the weblogic-ejb-jar.xml to say
<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-tx> in the
<persistence-descriptor> tag.

Setting the Database-is-Shared attribute to false will reduce the number of
ejbLoad()s to only happen at the beginning of transactions, otherwise a load
is done at the beginning of every method.

Hope this helps,
Anthony


-----Original Message-----
From: Jerson Chua [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 01, 2000 3:20 AM
To: [EMAIL PROTECTED]
Subject: Re: Transaction


Weblogic 5.1 with sp4. Im going to try sp5 on monday.
--- Gene Chuang <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Which ejb server and what version are you using?
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> To: [EMAIL PROTECTED]
> Sent: 8/31/00 11:48 PM
> Subject: Re: Transaction
>
> Have anyone encountered similar problem? Is it normal that ejbstore is
> deferred until the
> transaction ends?  My impression is that transaction isolation is
> handled by the DB but
> it seems to me that the application server is doing it instead.
> Experts... please
> comment on this.
>
> Jerson
>
> --- Rajan Kashyap <[EMAIL PROTECTED]> wrote:
> > Hi Dave,
> >         I didn't get the exact meaning of
> >         "there can be two physcial instances of a single EJBObject of
> "id" which is
> > causing the local diamond to form."
> >
> >         Can you please elaborate a bit more..
> >
> > Thanks,
> > Rajan
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
> > Sent: Thursday, August 31, 2000 6:05 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Transaction
> >
> >
> > It appears you have a somewhat off topic version of a local diamond
> forming.
> > Here is the issue.
> >
> >          methodA() {
> >                  eb1 = ebhome.findByPK(id);
> >                 // container calles ejbLoad() loading 111
> >                  eb1.setXXX(222);
> >                 // set is called on eb1 but since we are in tx
> >                 // the container fails to call ejbStore() waiting for
> a
> >                 // tx boundry.  Performance enhancement.....
> >                  System.out.println(eb1.getXXX()); // returns 222
> >                 // reading 222 from instance level data.
> >
> >                  // just tried this after my original post
> >                  eb2 = ebhome.findByPK(id);
> >                 // container calls ejbLoad() loading 111 as this is
> what is
> >                 // in the database as eb1 never had ejbStore() called
> on it
> >                  System.out.println(eb2.getXXX()); // returns 111 -
> PROBLEM
> >                 // reading 111 from instance level data
> >
> >
> >                  return methodB(id);
> >
> > Remember there can be two physcial instances of a single EJBObject of
> "id"
> > which is causing the local diamond to form.  The container should be
> keeping
> > track of every instance of an EJBOBject for id and assuring no diamond
> > forms.  In this case, the container should know a setXXX method was
> called
> > and ejbStore() is yet to be called, so when findByPrimaryKey() causes
> the
> > ejbLoad(), the container should force eb1 to call ejbStore() first to
> > maintain consistancy.
> >
> > The diamond is now compounded because eb1 and eb2 have differing
> states for
> > XXX.  If the container calls store() on eb1 then eb2 the value will
> rever
> > back to 111.  Seems like 1) The container should have detected this
> diamond
> > and 2) its a good reason for optimistic locking :)
> >
> > Just my read on whats happening.  Any other ideas anyone?  Ive not
> seen a
> > diamond like this one before, so Im not 100% sure of my diagnosis but
> it
> > makes sense.  The part I dont understand is why there was no locking
> issue.
> > That could only happen with eb1 and eb2 used the same connection?
> That
> > would be kinda odd too......
> >
> > Dave Wolf
> > Internet Applications Division
> > Sybase
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jerson Chua
> > > Sent: Thursday, August 31, 2000 10:12 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Transaction
> > >
> > >
> > > Hi Dave...
> > > The Session bean is stateless.  The Entity bean is bean managed.
> > > The entity bean is
> > > properly implemented (ejbload and ejbstore).
> > > All methods' transaction attribute are set to requires (this is
> > > tentative), Isolation
> > > level is set to serializable.
> > >
> > > here's a pseudo code
> > >
> > > // eb.xxx's original value is 111
> > >
> > > class StatelessSession {
> > >
> > >         methodA() {
> > >                 eb1 = ebhome.findByPK(id);
> > >                 eb1.setXXX(222);
> > >                 System.out.println(eb1.getXXX()); // returns 222
> > >
> > >                 // just tried this after my original post
> > >                 eb2 = ebhome.findByPK(id);
> > >                 System.out.println(eb2.getXXX()); // returns 111 -
> PROBLEM
> > >
> > >                 return methodB(id);
> > >         }
> > >
> > >         methodB(id) {
> > >                 eb3 = ebhome.findByPK(id);
> > >                 System.out.println(eb3.getXXX()); // returns 111 -
> PROBLEM
> > >                 return eb3.getYYY(); // return a value object
> > > which contains subset of the entity
> > > bean's atrributes
> > >         }
> > > }
> > >
> > > Is it because the isolation level is serializable? I think the
> > > change made in methodA
> > > should reflect in methodb since both methods are under the same
> > > transactional context.
> > >
> > > Am I missing something? please guide me.
> > >
> > > thanks in advanced.
> > > Jerson
> > >
> > >
> > > --- Dave Wolf <[EMAIL PROTECTED]> wrote:
> > > > Can I get a little better description?  Is this BMP or CMP?  Is
> > > methodA()
> > > > calling methodB() or is the client calling methodB() right
> > > after methodA().
> > > > What Tx level are both beans set to?  I assume we have a
> > > session bean which
> > > > contains methodA() and methodB()?  Stateful or stateless?
> > > >
> > > > Dave Wolf
> > > > Internet Applications Division
> > > > Sybase
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: A mailing list for Enterprise JavaBeans development
> > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jerson Chua
> > > > > Sent: Thursday, August 31, 2000 5:45 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Transaction
> > > > >
> > > > >
> > > > > Hi...
> > > > > I've a methodA which modifies the value of an entity bean. After
> > > > > the modification is
> > > > > performed, a methodB is called which finds for the same entity
> > > > > bean and retrieves the
> > > > > modified attributes.  My problem is the changes made on methodA
> > > > > does not reflect to the
> > > > > entity bean in the methodB.
> > > > >
> > > > > thanks in advanced.
> > > > >
> > > > > Jerson
> > > > >
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to