Check out Chris Raber's response. The key here is that you have only one
logical instance. The EJB server can, if it choose to implement it that
way, have many pooled physical instances. You bring up the problem with
physical pooling of entity beans, but nonetheless it's done. How you handle
the synchronization depends on the EJB server and/or the RDMS server you
use. The alternative, which you're describing and which doesn't have
synchronization problems, does has performance issues. If you have several
thousand people trying to access the same entity bean instance, they'd have
to wait in line for the resource.
-D
-----Original Message-----
From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 06, 2000 7:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Entity bean question: Multiple instance
Dan Brown wrote:
>
> I don't think your flight/plane is accurate. If entity bean instances
> couldn't be pooled, you could potentially have thousands of users trying
to
> get to the same flight/plane and ending up waiting in line! Imagine if
that
> was the way SABRE was architected!
Pooling != caching != multiple instances
Entity beans can be pooled all right, and still one instance per
transaction, which can be cached or not. And one implies nothing of the
other,
Now imagine that your plane entity bean is multi-instanced, one per
user. Either some users end up sitting on the same seat, or too many
users end up getting a transaction aborted exception. The only way for
you to make sure they don't end up in the same seat is by synchronizing
access to the seat.
BTW I hate to think of SABRE using entity beans to begin with, but the
your local reservation office can.
arkin
>
> -D
>
> -----Original Message-----
> From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 05, 2000 9:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity bean question: Multiple instance
>
> > The part that gets me is that I've seen references (in both books and
> here) of the same entity bean (of, say record A) can have multiple
instances
> (all are record A, not record A, B, C, etc) referenced by multiple
clients.
> But I have seen no examples of such to illustrate the scenarios where
having
> multiple instances of the same bean are desirable.
>
> First, forget all that you have learned about OODBMS. OODBMS enforces
> single object per identity (database record), while O/R mapping can
> support multiple objects viewing the same identity.
>
> EJB is neither an OODBMS, not O/R mapping, not assumes persistence. But
> it is modeled after the O/R mapping, and in O/R mapping (as in all RDBMS
> activitie) it is desirable to have multiple access to the same identity.
>
> Consider the situation where two customers are interested in buying a
> ticket on the same flight. Each customer will have a single instance of
> a ticket bean, but both will use the same instance of the flight/plane
> bean. They may be served by the same, or by different EJB servers.
>
> > Is this flexibility in EJB (compared to OODB or persistent Java) purely
> for performance optimization?
>
> No, this flexibility is part of the relational database world way of
> working. This is something OODBMS never managed to do right and in my
> opinion the reason why they never succeeded in the enterprise world.
>
> arkin
>
> >
> >
>
===========================================================================
> > 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".
