Denis,
If you modify an entity inside of a transaction, the app server will use the
DB transaction isolation, so it will not call any more ejbLoad (may be app
server dependent).
To solve performance impact of sharing the DB you can
- start and commit carefully the TX to avoid ejbLoad to be call, and
use isModified pattern to optimize ejbStore
- use optimistic locking to control DB sharing, but it require much
more coding.
Tibo.
http://www.valtech.com
> In this presentation, Ed indicated you could optimize
> our redundant database loads by checking in ejbLoad
> for whether the database is shared with another
> application. If not, then you are free to not reload
> the object (assuming of course it is not the first
> ejbLoad call since ejbActivate).
>
> Well from your esteemed answers to my original question
> I have to conclude that this is a dangerous performance
> enhancement. If one bean instance is caching the
> data and has properly written it at the end of a
> transaction, then the second would never see the
> update.
>
> The performance enhancement could still work for
> read-only beans.
>
>
> > ----- Original Message -----
> > From: "Dupont, Dennis" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, August 15, 2000 12:50 PM
> > Subject: Is there a guarantee of uniqueness for entity beans?
> >
> >
> > > I have looked through the EJB 1.1 spec for a requirement
> > > that containers guarantee that entity beans in the ready
> > > state are unique (i.e. that there is never more than
> > > one instance of a bean with a given primary key value).
> > >
> > > I cannot find such a guarantee, but I would expect one.
> > > Does anyone know if this is indeed the case?
> > >
> > > Thanks!
> > > Dennis Dupont [EMAIL PROTECTED]
> > > Quentra Networks (972) 889-5252 (Voice)
> > > 2121 N. Glenville (972) 671-2311 (Fax)
> > > Richardson, Texas 75082
> > >
> > >
> > ==============================================================
> > =============
> > > 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".
> >
>
> ==============================================================
> =============
> 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".