>> [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
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: David Rauschenbach/ZLAND)
Subject Re: Modeling an application with parallelism
: using EJB
Randy
You may be able to create a bean for each subprocess, the them to doWork
with
the given criteria and then listen for completion events from each
worker bean.
I'm sure there will be interesting responses.
Tony
----
Mcree, Randy wrote:
>
> Dear EJB'ers,
>
> My colleagues and I were attempting to model a telco application using
EJB.
> The application currently runs on a CORBA server and makes heavy use of
> threading to perform work in parallel. Because of the programming
> limitations in EJB (cf section 16.4) we are not sure that we can model
this
> application in EJB?.
>
> This application creates customer's phone bills. For each customer, the
bill
> consists of the aggregation of the costs over all phones during the
billing
> period. The costs are contained in call detail records. These records are
> stored in a partitioned database, spread across many physical disks, in
> order to support simultaneous queries. The current application creates
> subprocesses which more or less simultaneously queries all of a
customer's
> phones for records within a given time span. The result of each
subprocess
> is asynchronously returned to an aggregation function which waits for all
> subprocesses to "report in". It seems like this aggregation function
cannot
> be implemented as an EJBean because, as a bean, it cannot spawn threads,
> which is key to creating the necessary parallelism. The parallelism is
> necessary in order to complete the bill in a reasonable time. Note that
the
> hardware of the system is set up for this task: multiple disks, multiple
> cpus, multiple paths from cpu to disk...we need the software to take
> advantage of these capabilities.
>
> If we stick the aggregation function into, say, a CORBA server, then the
> question becomes, why EJB? There is a lot of business logic at that point
> (tax calculations, customized customer items, etc.) that seem beneficial
to
> express within a bean.
>
> Thanks in advance for any insights...
>
> Randy McRee
> Sr. Software Developer
> Tandem division of COMPAQ
>
>
===========================================================================
> 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".
--
Tony Holderith | Interactive Business Solutions
[EMAIL PROTECTED] | NetCentric Solutions
http://www.interactivebusiness.com | Business Objects
voice: 310.414.6760 | fax: 310.414.6759
Don't connect to the Internet - be there. IBS
===========================================================================
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".
