Hi, all. Something came up in EJB design discussion yesterday that I find hard to believe. If we multi-thread in our EJB "helper" classes, it is easy to have the threads all participate in the same transaction (transaction context), simply by opening another pooled Connection on the XA Datasource. But it was brought up that, in EJB (1.1 at least), we were not supposed to use multi-threading, since the container is already doing it's own multi-threading, i.e. it was not recommended by the EJB spec: http://archive.devx.com/premier/mgznarch/javapro/2000/03mar00/mm0003/mm0003.htm First off, is that true for EJB 2.0 as well, and if so, is there any other "approved" way we can do parallel processing in J2EE and have all work done in the same transaction context? Respectfully, Ben Ethridge
Hi, Pradeep. That a nice introduction to MD-EJB, but doesn't really address the fundamental problem: the transaction. Note that one user asked a similar question in the discussion thread at the bottom of the article (See Griffin 7/22/03 "Transactions?") Anyway, here's my essential question: Can the MD-EJB's carry the CMT transaction context on from one side of the asynch boundary to the other: -------------------------------- Client EJB calls: TX_Required Stateless Session EJB A sends multiple asynch message to: TX_Mandatory Message-driven EJB B who,for each message calls: ...and note tx context holds through to here: TX_Mandatory Stateless Session EJB C and then... TX_Mandatory Message-driven EJB places response messages on out-que. ...same tx context as before... TX_Required Stateless Session EJB A rcvs all messages from the in-que.
Client EJB sees something in a message it doesn't like, executes setRollBackOnly() and exits. Container rolls back all work done in EJB A thru C. ----------------------------------------------------- If not, is there some other "approved" way of doing this? We can do it all with threads in EJB helper classes, but we don't want to, because it isn't recommended by Sun. So what's their alternative? Respectfully, Ben
Unfortunately, MDBs cannot participate an existing transaction (see EJB 2.0 spec, chapter 15.4.7) so they are not an option. I would probably just use threads and take my chances knowing that I'm breaking the specification...
Thanks, that's pretty clear in the spec. Unfortunately, we made a small boo-boo in our prototype, so I have to take back a bit of what I said at the start of this discussion. Now we're not positive that we can pass the CMT XA DataSource to the new thread (or the Runnable passed to the new Thread). So you know, in our EJB "helper" classes, we use a PROGRAMMATICALLY acquired Connection from the XA DataSource pool of connections. The container and the EJB participate in this transaction context as well, but I'm talking about all CMT/BMP here (i.e. not BMT/BMP and not CMT/CMP). I'm trying to imagine how the container could disallow the new thread from participating in the transaction. How would it ever know? We'll let you all know what our prototyping uncovers. Gotta go on vacation now. Back in a couple of weeks. One of my associates who's working on this at our office may (or may not) pick up on this discussion thread for me. Respectfully, Ben
Joined: Jan 23, 2002
It would be nice to hear from your prototype, guys. Please keep us posted
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Message-driven EJB's and transaction boundary question