Hi Robert,
In the inprise documentation they do elaborate on this association a bit
more:
Sidebar:
Implementing this parallel transaction feature is non-trivial for most EJB
container vendors, because it requires a relatively sophisticated
server-side object dispatch model. What is required is the ability to
dispatch on a server-side object using both the primary key (which is
usually embedded in the object reference) and the current transaction. Doing
this multi-key dispatch is very hard to implement on top of an RMI or BOA
style server-side model, which is why no other EJB container provides this
functionality. We leverage the POA, which is a server- side frame-work which
is much more sophisticated, and which is much more conducive to implementing
this functionality.
I have never implemented a server side multi-key dispatching model in RMI so
maybe somebody else can elaborate on what the issues are in doing this. I
would consider it slightly more complex considering the transactional
context propagation involved and the implementation would have to be pretty
good to achieve relatively good performance which is the whole point.
kind regards,
William Louth
> -----Original Message-----
> From: Robert Patrick [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 19, 2000 1:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: An easy way to create an in-memory-database entity beans
>
> Hi William,
>
> At 10:35 AM 4/17/00 -0400, you wrote:
> >http://www.inprise.com/devsupport/appserver/faq/Availability_Scalability_
> Per
> >formance.html
> >
> ><extract>
> >1. Parallelized access to Entity Beans. Other EJB containers have to
> >"serialize" the call to the Entity bean which affects the scalability and
> >performance. Without a POA like infrastructure your Entity Beans WILL NOT
> BE
> >ABLE to service multiple client invocations simultaneously. That is a
> >serious limitation if you are looking to service millions of concurrent
> >transactions.
> ></extract>
>
> I realize that these are not your words but I sure would be interested to
> hear the justification for this statement. The POA does provide a good
> infrastructure for managing server-side object life cycles and such (and I
> agree that it is very useful in scaling to support millions of server-side
> objects -- though similar non-CORBA-based mechanisms could be built to
> achieve the same results). However, I do not see the connection between
> the POA and optimistic locking of entity bean instances which the
> statement
> appears to say cannot be accomplished without a POA-like
> infrastructure. Hopefully, someone will educate me as to why this is a
> valid statement.
>
> Thanks,
> Robert
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
