A few comments: + Stateful services, although useful from time to time, is are a bad idea from a scalability point of view. You won't find them in .NET, and you won't find a multithreaded version in J2EE. You will find them in Corba, but that doesn't make it a good thing.
+ You don't need multithreaded synchronization to do what you're describing. You can synchronously call JMS's session.receive() to pick up the reply messages. I wrote a whole framework to encapsulate this whole thing behind job executors and result futures so you can even hide the MDB plumbing. + Make sure your JMS session.send(msg) and session.receive() are outside of a transaction. Otherwise, messages aren't sent until after the transaction commits, and you'll end up with deadlock. + Why rewrite an existing, working solution just to say it's J2EE? J2EE isn't always the right choice. On Wed, 31 Mar 2004 09:52:25 -0800, McKnerney, Michael D (US SSA) <[EMAIL PROTECTED]> wrote: >Hi, > >We're in the process of migrating an app that is based on C++ and CORBA to J2EE. > >We have this simple design right now, that goes like this. > >- Stateless Session bean is the facade that clients use to doWork() > >- doWork() > + creates a stateful EJB to hold results (resultBean) > + sends a msg to different JMS queues, each responsible for doing different work, passing along a handle to the resultBean > >- When JMS queue workers finish, they send the results in a resultMsg to a JMS result queue hosted by the EJB container > >- A MDB onMessage() fires within the EJB container an then sends the result to the resultBean via its handle > > >This means that the resultBean must be multithreaded and, therefore, must use synchronization. > >I've read through the "Opinion: EJB Limitations. Can you break them? Can you not?" on TSS, and from what I can tell, using any form of synchronization in the EJB, or any object it might delegate to, is non- compliant. > >The remark that made this hit home for me was Message #104977 by Bill Burke where he states: > >"My beef with EJB's is that there is no concept of a service. Multi- threaded objects that can retain state. " > > >Seems like our design would be very common and so how does one go about achieving this in a compliant way? > >Thanks for any suggestions, >Mike > >=========================================================================== >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". =========================================================================== 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".
