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

Reply via email to