| Author |
Message
|
| kolban |
 Posted: Wed Mar 26, 2003 2:39 pm Post subject: Architecture query: JMS calls in a stateless session bean .. |
 |
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Folks,
Imagine you have a stateless session bean and you want to put a message to a JMS queue. In my bean, I could create a QueueConnection, QueueSession, QueueSender and put a message and then close the objects. This will certainly work ... but ...
Since it is expensive to create QueueConnections and QueueSessions, should I invent a mechanism to keep those objects around and cached between uses?
What have y'all been doing in your own applications? |
|
| Back to top |
|
 |
| yaakovd |
| Posted: Mon Mar 31, 2003 4:48 am Post subject: |
|
|
Partisan
Joined: 20 Jan 2003
Posts: 319
Location: Israel
|
Looks great!
It is the same idea like connection pool for DB. what's different? In both cases we need good performance.
We are using MDB in our application server, but I think it really good solution for stateless beans.
_________________
Best regards.
Yaakov
SWG, IBM Commerce, Israel |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 31, 2003 7:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Have you looked at the support for JMS Application Server Facilities?
They're described in chapter 13 of the Using Java manual (at least, for 5.2 they are). |
|
| Back to top |
|
|
| Rclements |
| Posted: Mon Mar 31, 2003 4:49 pm Post subject: RE:JMS calls in a stateless session bean |
|
|
Novice
Joined: 20 Jun 2002
Posts: 18
|
Here are a few morsels to consider. If you are operating with transactions you will uncover a little uglyness.
Unlike Statefull beans, stateless session beans do not receive any notification about jta transactions. This creates a dilemma with respect to transaction boundaries. How do you know when the transaction is complete?, and consequently when do you know to get a new session ? (avoiding illegalstate exception)
One technique we used was to get a new session for each call. This worked, but it just doesn't leave you with a warm fuzzy. After much discussion (with colleagues), IMHO, I would say that if your bean is going to have any state associated with it (like JMS connections, JTA transactions, etc ...) using a stateless bean for its implementation is questionable at best.
Also, btw, the same code running as a stateless vs. a statefull bean yielded a 1:2 performance ratio (read statefull took twice as long to do the same work)
just some stray info... hope its usefull
ricardo clements |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Apr 01, 2003 8:39 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| The application server framework is used by the EJB Container to read messages from queues and deliver those to messages to MDBs. I don't think there is a use for putting messages to queues nor to get a connection or session from the application server facilities. |
|
| Back to top |
|
|
| Rclements |
| Posted: Wed Apr 02, 2003 5:16 am Post subject: |
|
|
Novice
Joined: 20 Jun 2002
Posts: 18
|
Perhaps I'm confused.
This thread started with "Imagine you have a stateless session bean and you want to put a message to a JMS queue", and I was trying to share some experience with respect to doing this.
Also, the comments "... Since it is expensive .... should I invent... cached ..." touched on this experience as well, especially if a transaction was involved.
Your reply has me scratching my head.
You seem to discount the "Imagine ..." statement by saying "I don't think there is a use for putting messages to queues nor to get a connection or session...".
ricardo clements |
|
| Back to top |
|
|
| LeaThurman |
| Posted: Wed Apr 02, 2003 5:54 am Post subject: |
|
|
Newbie
Joined: 02 Apr 2003
Posts: 1
|
Kolban,
I am a little confused aswell. I was always under the impression that application server facilities (ASF) and server session pools (SSP's) were used in situation where MDB's were not an option.
Regards
Lea. |
|
| Back to top |
|
|
| kingdon |
| Posted: Wed Apr 02, 2003 11:07 pm Post subject: |
|
|
Acolyte
Joined: 14 Jan 2002
Posts: 63
Location: UK
|
Neil is correct - the ASF facilities described in chapter 8 of the JMS spec' deal only with incoming messages. There's nothing there to help with sending messages on the outbound leg.
My take on Neil's original question is that the recommended approach is for each method invocation to lookup a connection factory, create a connection, session and message producer and send the message. It's then the vendor's responsibility to make it perform well by implementing cacheing/pooling/sharing etc. From an architectural point of view, I would have liked to have seen some vertical restructuring on the JMS classes, allowing simple messaging to be done with just a Connection object instead connection/session/producer/consumer quads. But that fell on deaf ears and we got domain unification instead 
Cheers,
James. |
|
| Back to top |
|
|
| dtauzell |
| Posted: Tue Apr 29, 2003 6:47 am Post subject: |
|
|
Apprentice
Joined: 23 May 2002
Posts: 37
|
We have the same problem. I am currently working on a pool using the Jakarta Commons pool. Basically, there will be one connection per appserver and then a pool of QueueSession objects. When code using the session detects an error it marks it as invalid. Upon returning objects to the pool, if they are invalid they are closed.
I still have an issue if the QueueConnection goes bad. Also, there are tricky issues with transactions, subscribers, etc ... as mentioned. I'm still working out details. |
|
| Back to top |
|
|
|
|
