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?
JPL> This depends greatly on what you understand by cloning. Obviously, you're leaving Local interfaces out of this. 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 JPL> You make a mistake here; the whole iteration should spawn 1 single transaction. You can have the read-only JDBC call out of the transaction, but the whole iteration should be run under a single transaction, if possible. Otherwise you're paying the price of starting and commiting a transaction for each id. JPL> How about this solution roughly based on your approach: 1) 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" 2) Servlet method sends JMS messages to a number of servers in a round robin fashion from a list loaded by a Properties object (from a file or a DB or whatever you want), or if the JMS service is clustered, to just one server. The message is the description of a mini-batch/task job to be performed. 3) Each time an MDB receives a task, it calls processId(id) on a Session Bean HTH, JP PS: Do you mind not using HTML for the messages? It makes them quite difficult to answer... =========================================================================== 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".
