Isn't there is a potential problem with having two distinct entities
representing the same identity and pushing locking into the database? The
problem is the danger of deadlock if they are used concurrently in different
transactions. If they both read-for-update then deadlock will ensue. Best
case scenario is that one of the transactions will abort if deadlock is
detected by transaction timeout or if the database detects the problem.
Simon.
----- Original Message -----
From: "James Cook" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 15, 2000 8:39 PM
Subject: Re: Is there a guarantee of uniqueness for entity beans?
> The performance enhancement still works, however the control of
concurrency has
> to be pushed back on the database. What Ed is describing is referred to in
the
> spec as Option A commit time option. I recommend that customers stay away
from
> Option A because it is nearly impossible to guarantee exclusive access to
beans,
> especially in the future.
>
> If you are interested in writing truly portable entity beans, you *have*
to
> control concurrency at the database level, or at some place between the
EJB
> container and the database. This is true simply because many containers
choose
> to use multiple instances of entity beans to ensure thread-safe access.
Note:
> This rule applies no matter what the concurrency model is.
>
> jim
>
>
> ----- Original Message -----
> From: "Dupont, Dennis" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 15, 2000 2:57 PM
> Subject: Re: Is there a guarantee of uniqueness for entity beans?
>
>
> > Thanks to Jim, Tibo and Dave for the responses.
> >
> > The reason I brought this up was I was playing with
> > implementations of Ed Roman's performance tips (see
> > http://theserverside.com/resources/patterns_optimizations_roman.pdf).
> >
> > 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".
===========================================================================
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".
