I guess that you could get a race between MDB2 starting and MDB1 committing if (a) you use a file based JMS persistence manager and (b) you are not including the JMS messages in the transaction. Then it is possible for the thread running MDB2 to start before the thread in MDB1 has finished.
That would suggest that, if you persevere with this architecture, you should use a JDBC based persistence manager and include handling JMS messages within the transaction. That involves getting a reference to the Transaction Manager and calling the begin() and commit() methods on it. Making message handling transactional also avoids problems if the database commit fails but the messages are still processed. I think, however, that refactoring would almost certainly be a quicker and more reliable method of resolving the problem. If you can tell me what your application is trying to do, I may be able to suggest an alternative design pattern. James View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847556#3847556 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3847556 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
