File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Message-driven EJB's and transaction boundary question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Message-driven EJB Watch "Message-driven EJB New topic
Author

Message-driven EJB's and transaction boundary question

Ben Ethridge
Greenhorn

Joined: Dec 20, 2002
Posts: 6
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
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

www.javaworld.com/javaworld/ jw-07-2003/jw-0718-mdb.html


Groovy
Ben Ethridge
Greenhorn

Joined: Dec 20, 2002
Posts: 6
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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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...


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ben Ethridge
Greenhorn

Joined: Dec 20, 2002
Posts: 6
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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
It would be nice to hear from your prototype, guys. Please keep us posted
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Message-driven EJB's and transaction boundary question