> Sounds like the RDBMS does all the hard work anyway.
Actually, no. That is part of the problem, a single SQL query, no matter how
complex, only involves one cpu. That cpu can touch as many discs as
necessary, but the single cpu limits the speed. So this application tries to
get as many SQL queries going as possible, up to some tuning limit which
depends on the optimal number of simultaneous SQL queries per cpu.
(Typically talking sixteen or more cpus and a room full of discs)
As a middleware developer I would like the customer to be able to write a
straightforward EJB application and then get it to scale to this size
system...
Randy McRee
> -----Original Message-----
> From: David Rauschenbach [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 11, 1999 3:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Modeling an application with parallelism using EJB
>
> >> [tell] them to doWork with the given criteria
>
> Since EJB's are not allowed to make synchronization calls or start
> threads,
> these doWork methods must be called synchronously.
>
> >> and then listen for completion events from each worker bean
>
> Again, "listening for completion" eludes to using synchronization
> mechanisms being used in the evoker bean, which is ruled out by the spec
> in
> sec 16.4.
>
> I don't see room in the EJB spec for implementing the given solution. The
> invoker session bean (equiv.) could possibly be non-EJB, which leaves at
> least some of the system (the workers) in EJB. But that sounds lame, I
> wonder if this system isn't best left alone. Sounds like the RDBMS does
> all
> the hard work anyway.
>
> David
>
> Tony Holderith <[EMAIL PROTECTED]> on 03/11/99 03:18:51
> PM
>
>
===========================================================================
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".
