I'm sure you know by now how difficult is to implement a good and optimal thread management in a multithreaded, eventualy distributed system (supposing you're not using a container and you'd have to do this work yourself). If in top of that you'd consider implementing a transactional system as well, where multiple local or global (distributed) transactions and concurrent threads are associated you can imagine the complexity of such system. If your EJB container will allow programmers to interfere with the thread management then an entire Pandora's box of malefic possibilities will be wilde openned. The result will mostly be catastrophic and will break the container's transaction management. As for the "innocent" thread.sleep() inside of an SLSB or MDB one might guess what could happen: the current thread that owns the bean instance will sleep. The transaction associated with that thread will block as well. Now you know that one of the secrets of designing optimal transactions is to make them as short as possible. Even worse, if your transaction uses a pesimistic locking approach than database locks will be held resulting in database deadlocks as well. On the other hand, if you'd consider global transactions and the 2PC protocol, you'd remark how complex the problem will become. Regards.
I think, therefore I exist -- Rene Descartes
Joined: Mar 15, 2005
I was thinking of the doing the Thread.sleep() to send only certain # of Messages (to the Jboss Msging service) at a time. ( I looked up a DB counter that was updated by each of the Child MDBs before they finished execution. That way I could enusre that X # of msgs were always processing)
But now I am sending all possible messages to the messaging service(jboss). The # of MDB instances in the pool has to be very low though. Hopefully the queue will hold a few thou msgs.
Anyways, I think there's gotta be a better solution than that too.