RE: [Springframework-developer] JMS questions

[Mark P. <mar...@co...>]

Hi,

I'm developing the JMS support for Spring so I hope I can answer your
questions.  The class that you can use for you sending needs is =
JmsSender
with 1.0.2 and 1.1 implementations.  The interface is likely to be =
renamed
JmsTemplate.  This replaced the classes P2pTemplate and PubSubTemplate,
which are no longer in the sandbox.

Inside an EJB the call to =20

topicSession =3D
     topicConnection.createTopicSession(true,=20
			 Session.AUTO_ACKNOWLEDGE );

Should ignore the values set to both the transaction and the =
acknowledgement
mode.  The values come from the transaction properties declared on the =
EJB.
Section 17.3.5 of the ejb spec talks about this.

For BEA, the behavior of using JMS inside an JMS is discussed at
http://e-docs.bea.com/wls/docs81/jms/j2ee_components.html, which might
provide some insight.   For example, to get the tx enlistment behavior =
you
need to declare the jms connection factory as a resource-ref in the
deployment descriptor to get the advanced functionality of its JMS =
wrapper
classes.

The fact that you are affecting the behavior of the app by changing the =
tx
mode, indicates that somehow the container isn't managing the tx mode.   =
You
probably don't see a message published when txmode =3D true because you =
need
to explicity do topicSession.commit() if the container isn't managing =
the
tx.  The timing issue in the case of tx=3Dfalse is expected, since the =
db
update and jms than aren't occurring together, the jms message probably =
gets
to the client first quite frequently I'd guess.

The JMS transaction support from the spring JmsSender class is basically
delegated to the behavior on the container since it just a wrapper to =
the
execution of a createSession method.  Check the configuration of the app
server to make sure jms tx's get enlisted.=20

The container would try to use XA if you request the db update and the =
jms
update in the same transaction and would throw an exception if the jms
connection factory was not XA-enabled.  Depending on your performance
requirements, you might not want to go that route.   Instead you could
separate out the separate out the db update and the jms update into two
separate EJBs, with independent tx's, and have the db update occur =
first.
You have so examine if the failure scenario is ok for you in that case.
Alternatively, you could send the update information in the update =
message
itself, which would probably be better since otherwise you could have =
the
case of potentially many (100's) of clients all asking the database for =
the
same information at the same time. =20

Email me privately if you want to work through this is more gory detail =
that
might not be appropriate for a larger audience. =20

Cheers,
Mark

Email:  mar...@co...







> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of Les A. Hazlewood
> Sent: Monday, June 28, 2004 3:19 PM
> To: spr...@li...
> Subject: [Springframework-developer] JMS questions
>=20
>=20
> Hiya folks,
>=20
> I was wondering if anyone had any thoughts on when the JMS=20
> components would be integrated into a Spring release?  I'm=20
> not looking for any specific dates...just a ballpark figure=20
> (and yes, I know that this is an Open Source product, so I=20
> take ballpark figures with a grain of salt...I'm just looking=20
> for something, anything).
>=20
> Also, I was wondering if anyone could help me out with some=20
> insight....
>=20
> Here's my issue:
>=20
> An EJB method is called from a remote client.  In response to=20
> that method call, some data is processed, saved back to the=20
> db, and then a JMS message is published to all clients who=20
> care about that data.  The data is not committed until the=20
> end of the transaction.
>=20
> The JMS message is received by a client which then=20
> immediately requests the data that was just updated.
>=20
> Occasionally, when the client requests this data, it doesn't=20
> get what it expects.  The reason for this is that we think=20
> the client is making a request for the data before the first=20
> transaction has had a chance to commit/flush.
>=20
> So, basically, we'd like to sync the JMS sending to only send=20
> upon transaction commit, to ensure that the data will be in=20
> the db by the time the clients request it.
>=20
> I tried setting the JMS transacted attribute to true when=20
> creating a topic session, i.e.
>=20
> topicSession =3D
>     topicConnection.createTopicSession(true,=20
> Session.AUTO_ACKNOWLEDGE );
>=20
>=20
> After reading the JMS spec, this is all that should be=20
> necessary when participating in transactions in a J2EE container.
>=20
> However, we're seeing that the client's don't receive _any_=20
> messages from the server when set to true.  When set to=20
> false, the messages are being sent, but that synchronization=20
> issue pops its head up.
>=20
> Does anyone have any insights on why this is happening?
>=20
> Also, does the Spring JMS support in the sandbox already work=20
> with integrating into transactions, like the Spring Hibernate=20
> support does?
>=20
> Any ideas would be graciously received.
>=20
> Regards,
>=20
> Les
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings &=20
> Training. Attend Black Hat Briefings & Training, Las Vegas=20
> July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20