Multithreading batch processes/Session bean calls within cloned Application Server environment

I have the details mocked up for a code simulation to multithread our
EJB-based batch processing, and I have some questions. See the last two
paragraphs for the context driving this problem. The simulation I've
developed does not use EJBs, but addresses most of the multithreading
issues. Here are my questions:

*       If a servlet in a cloned Application Server environment spawns
threads (note the security authentication issues are already solved) and
the multiple threads include Session Bean calls, will the Session Bean
calls be workload-managed? For example, in a cloned application server
with two servers - machine A and machine B, if I spawn eight threads in
a servlet call on machine A, can we ensure that some of the Session Bean
calls made inside those threads will be executed on machine B, as well
as some executed on machine A?
*       If the above can't happen, then how do we accomplish multiple
threads operating in the application server where each thread includes
Session Bean calls and the calls are workload-managed across all
application server clones? Would an application client be able to
accomplish the same thing?

 

Background: Context driving the problem:

We have been considering different ways to speed up our EJB-based batch
processes. The current sequence of events is:

*       Servlet method calls a Session Bean method, call it batch(),
which has transaction attribute "Not Supported".

        *       batch() makes a read-only JDBC call to assemble a List
of ids of items to process
        *       batch() iterates through the ids singly. For each id,
calls another Session Bean method, call it processId(id), which has
transaction attribute "Required"

                *       processId(id) loads Entity Beans and processes
them (each entity bean's methods have transaction attribute
"Mandatory"), committing an EJB transaction

 

Other than streamlining the code in processId(id) so that it is as
efficient as we can make it, we wanted to explore another possibility:
multithreading the batch() call. Here is what I have in mind:

*       Servlet method makes a read-only JDBC call to assemble a List of
ids of items to process, and contains these in a "task pool"
*       Servlet method starts a "worker pool" of configurable size. Each
worker runs in its own authenticated thread. 
*       Each worker requests a task from the task pool. If no tasks
remain, the worker removes itself from the worker pool.

        *       Each time a worker obtains a task, the worker calls
processId(id) on a Session Bean

*       The process continues until the worker pool is empty.

 

Charles May

TDD/AFCO Systems Group

Mellon Financial Corporation 
The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. 
Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. 
If you are not the intended recipient please notify us immediately by returning the e-mail to the originator.(B) 

===========================================================================
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".