• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Message-driven EJB's and transaction boundary question

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
www.javaworld.com/javaworld/ jw-07-2003/jw-0718-mdb.html
 
Ben Ethridge
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Ben Ethridge
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would be nice to hear from your prototype, guys. Please keep us posted
 
reply
    Bookmark Topic Watch Topic
  • New Topic