EJBeans themselves cannot be multi-threaded, but there is nothing that says
a cient to EJBeans cannot be.
The various sub-queries/sub-processes could be implemented as EJBeans, but
the caller/client could be a non-EJBean Java/CORBA object which forks
threads (or uses pre-allocated worker threads...) to invoke on the
underlying EJBeans asynchronously. The Java/CORBA object that does the
multi-threading work could be wrapped by another session bean which provides
the coarse grained interface to this functionality. That session bean could
then invoke on the CORBA object which does the multiplexing work.
Course grained session bean -> Java/CORBA wrapper object, multi-threaded ->
several sub-process beans in parallel
An EJB server that propagates the transaction context from the wrapping
EJBean, to the CORBA object and then to the lower level query beans would be
good ;-)
The benefit would be that the individual queries sound like a good fit for
expression as EJBeans.
Hopefully the EJB spec gurus are considering how to add event models and
multi-threading to the EJB paradigm.
-Chris.
----------------------------------------------------------------------
Chris Raber, Systems Engineer, GemStone Systems Inc.
100 West Big Beaver, Suite 200, Troy, MI 48084
phone: (248)-680-6691, fax: (248)-680-6689,
email: [EMAIL PROTECTED]
web: http://www.gemstone.com/
----------------------------------------------------------------------
> -----Original Message-----
> From: Mcree, Randy [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 11, 1999 5:50 PM
> To: [EMAIL PROTECTED]
> Subject: Modeling an application with parallelism using EJB
>
> 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".
===========================================================================
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".
