| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| J2EE, Sending Messages with SL Session Bean or Singleton? |
« View previous topic :: View next topic » |
| Author |
Message
|
| teal |
 Posted: Wed Dec 15, 2004 11:59 am Post subject: J2EE, Sending Messages with SL Session Bean or Singleton? |
 |
|
Acolyte
Joined: 15 Dec 2004
Posts: 66
|
what would a J2EE expert recommend using in this situation a singleton or Stateless Session bean?
Multiple transactions are coming through the J2ee system running on WAS 5.1(mq53 is the jms provider, NOT embedded msg).
On the wait out, the transaction needs to be rebuilt as messages and sent to a legacy system running IBM websphere MQ 5.3 It is a Very high volume.
Currently I have created a SLSB that builds a JMS message and places it on a remoteQ defintion which is great because I can take advantage of pooling and it works great, but, I have all the initialization code
( QCF & Queue jndi lookup) in the the ejbCreate(), which is fine if the SLSB is always putting to the same remote Queue,
BUT now it needs to be putting to 12 different queues and I was told should not put the initialization code in the service method of the session bean , so should I go to a singleton instead? what are the advantages of using a singleton over the SLSB? Hope someone else can shed some light on how they are implementing a "message sender" in J2ee.
thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Dec 15, 2004 3:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You are fine with a singleton if you are looking for the connection.
However the qsession should be instantiated depending on your transaction border needs.
i.e. each thread should instantiate its own qsession.
Now you can put to however many queues you want within the same thread/qsession.
Just remember you will need to define at least one sender.
Look up the manual and read about the anonymous sender (you define one sender and pass the queue as a parm to the sender). You can also use one sender per queue.
DO NOT FORGET to CLOSE the SENDER when you don't need it anymore.
Do not wait for it to be garbage collected.
Now if you need to control the qconnection (start, stop) then you should instantiate your own. (factory, connection, session)
Enjoy  |
|
| Back to top |
|
|
| teal |
| Posted: Wed Dec 15, 2004 5:08 pm Post subject: |
|
|
Acolyte
Joined: 15 Dec 2004
Posts: 66
|
what "manual" are you referring to?
I scanned through the 'Using Java' but nothing..
thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 15, 2004 7:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Look up the using java manual pp 400-416 method on QueueSender:
queuesender.send(queue, message);
etc...
Enjoy |
|
| Back to top |
|
|
| teal |
| Posted: Wed Dec 15, 2004 9:47 pm Post subject: |
|
|
Acolyte
Joined: 15 Dec 2004
Posts: 66
|
I see what you are talking about. the overloaded send().
Let me ask you this though, could I not just have the SLSB just do a JNDI lookup on all the queues in ejbCreate() and depending on the data, send it to one of the queues that was already looked up? I still have the advantage of pooling/XA trans? and all the Session Beans are now capable of such through the EJB container? meaning each subsequent instance of the bean will already have the queue dest lookup already done, am I right?
One other question...
since I am using WMQ 5.3 as the full messaging provider isn't there way I can make a model queue and have the SLSB dynamically create a queue on the fly to put it on?
thanks again |
|
| Back to top |
|
|
| slaupster |
| Posted: Thu Dec 16, 2004 2:11 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004
Posts: 41
|
I would disagree that using a singleton is a good idea. While a valid approach in normal programming models, j2ee is very different.
Neither is there much performance gain (ie nothing significant) about doing the lookup in ejbCreate, in fact it can slow things down:
1) All the messaging objects are pooled according to the JCA settings anyway. So the lookup simply goes through the allocateConnection method of the PoolManager, which because of this exact reason, has been heavily optimised.
2) If your system is going flat out, you won't have much pre-emptive caching of the SLSB, negating any benefit of doing any work in the ejbCreate - i.e. there is no delay between ejbCreate and the invocation of your user methods, so if it makes it easier, do that work in your methods.
3) Holding the reference to the connection handle across method and tran boundaries, as you do by looking up the objects in ejbCreate can actually have performance penalties because the connection handle actually requires extra management in this case. This URL talks about Connection handle usage patterns and is a good read:
http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/cdat_cconpconh.html
Furthermore, by using a singleton, you raise transaction isolation issues which if not understood fully cause MQRC SYNCPOINT NOT AVAILABLE and a miriad of other issues.
I would definately encourage the get/use/close pattern as discussed in the above URL. Its far safer, and for most situations is actually more efficient. Note that JMS is treated as a backend resource (i.e. JCA wrapped) by WAS, both Connections and Sessions.
Looking up queues in ejbCreate is safe, but hardly worth the effort, especially if you must look up more than the one you are going to use. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
