Dan Brown wrote:
>
> 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.
This is known as lock contention and is unescapable, even if you
consider Chris's response and the GemStone architecture.
Let me explain. Picking up Flight as an example was pretty horrible of
me, since the Flight bean will typically be accessed for read only by
most client, those each one can see it's own entity bean.
A server can decide whether to have one entity bean for all clients or
one per client. But if you look at a distributed system, you might end
up having the entity in each airport and travel agency, not just in the
central mainframe, so you do end up with multiple entity bean instances.
The locking issue occurs when you actually try to reserve a seat on the
flight. So let's depart from Flight for a second and focus on
FlightSeat. You cannot allow two people to reserve the same space, you
must assure that only one transaction gets access to the same instance
at any given moment, whether you have one bean instance or two bean
instances representing the same seat.
The EJB server will take care of synchronization for you, which will
lead to lock contention if two passangers ask to be seated in the same
seat at the same time. However, considering < 500 passengers per
airplane and the fact that reservation and checkin are fairly serialized
operations (how many attendants are there to check you in at the
airport?), usually you don't get to concurrency conflicts. When you do
get into concurrency conflicts, the transactions are short enough to not
make a difference.
I hope that sets the record straight.
arkin
>
> -D
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
