Randy,
Here is a solution that can take full advantage of your multiple cpus, can
access your databases in parallel, allow you to do all your business logic
in EJBs and still have simple *single-threaded* clients.
As others have said it already, the EJB model does not allow you to spawn
threads in your beans. There are very well founded reasons for that and
lifting the restrictions would eliminate all the advantages of EJB itself.
If you use an *embeddable* EJB server (<PITCH>Ejipt</PITCH>), you can create
your own customized server solution that instantiates the EJB server
internally to handle your beans implementing transacted business logic.
So here is the solution:
1) write your beans as usual, using the full feature set of EJB including
entity beans.
2) write your clients as usual. Test them with a standalone instance of the
EJB server.
3) embed your EJB server into your custom server. Intercept the calls that
you would like to parallelize. Spawn the necessary amount of threads and
forward each thread to the embedded EJB server. When they all return, you
can call a method on the "aggregation" bean and return the result. Of
course, at this stage you have to be careful about the number of threads you
create etc. Since you are writing a custom server, outside of the EJB
domain, you have to be aware of how to manage resources. Nevertheless, in
your case, the customization code can be pretty straightforward. The only
resources it uses are threads.
Also, one more note. Since parallel calls coming in to the EJB server are
serviced in parallel (including db access), your resources are used at max
efficiency and as parallel as you wish (depending on how many bean instances
you allow to have and what your db locking strategy is and, of course, your
hardware).
Hope this helps,
Imre Kifor
Valto Systems
-----Original Message-----
From: Mcree, Randy <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, March 12, 1999 11:54 AM
Subject: Re: Modeling an application with parallelism using EJB (reply)
> > 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".
>
===========================================================================
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".
