axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maciej Szefler" <>
Subject Re: Transactional JMS.
Date Tue, 04 Sep 2007 19:15:02 GMT

Your take appears to be based on the assumption that AXIS is communicating
with the JMS provider directly (that is outside of a managed environment).
In a managed environment the connection/session creation would not be an
issue since these would  be pooled objects, with automatic transaction
association. In this (managed) case sending message in JTA would be only a
matter of a) providing a way to specify JNDI location of a JMS connection
factory, and b) making sure that the session is started with the transacted
flag set to false. In this context, the message consumption is problematic
since it would need to involve either MDBs or some unsightly polling scheme.

So assuming direct communication to the JMS provider (and no "magic" help
from the JMS provider) , I generally agree with your comments. Certainly
creating a connection for each connection is not acceptable (this is true
for the non-JTA case as well). The naming scheme that you describe would
work perfectly well for us, but it may quickly turn into a JCA-lite project;
perhaps there is some way to make this pluggable (a simple interface for
providing a JMS connection to AXIS). As for reusing sessions,I think it is
more trouble than its worth, and in my experience there is very little
performance overhead here. Also session-per-service would necessitate
serializing access (since an XASession can only be associated with one JTA
transaction), which in many cases would not be desirable.

Going direct, we still have a problem with receving messages. As far I know,
it is not possible to do a JTA receive using the async MessageListener
interface. One would need to either poll, or  use the MessageConsumer
interfaces. In either case there is the issue of who begins and commits the
JTA transaction (AXIS2 or the service), and if its the service, it is not
clear how that interaction would look. I'm more inclined toward an  MDB-like
model, where AXIS starts the TX, calls the service, and then barring some
indication to the contrary, attempts to commit.


On 9/4/07, Rajith Attapattu <> wrote:
> Maciej,
> Currently there are a few problems with doing this. Lets identify the
> issues
> a) We create a new connection for each invocation (sending messages)
> b) Hence we create a new session for each invocation.
> c) When creating a session for receiving as well as sending transacted is
> set to true - no way to configure this.
> d) We currently don't expose the session outside for both transport
> sender/receiver, hence you cannot call commit or rollback on it.
> e) Since u are using JTA I assume it's a distributed transaction. So we
> need to create an XASession instead of a normal session.
> This can be done and here are some ideas. I spoke with Asankha briefly on
> this topic once.
> a) Asankha pointed out a new connection is created for each invocation as
> each service could have different connection params. (different provider,
> username,..etc)
> The downside of this is that creating new connections is an expensive
> operation. Especially if the same service sends frequent messages it will
> keep recreating connections. We should make this behaviour configurable.
> I would like if we could reuse connections where we can. Also in most
> cases a deployment would use a single provider and we can definitely
> optimize for this case.
> For this case we can get away with a single connection per axis2 instance
> and session per service (one for sending and one for listening).
> If we can name connections then we could reuse them when defining
> services. This way we can check if an existing connection by that name
> exists and reuse it, if not create one.
> When we reuse connections there will be keep alive issues. Most providers
> have convenient and cheap ways of sending ping/pongs to keep the connection
> alive.
> So in a case where the service sends messages frequently this will help.
> If the service sends messages rarely and the cost of keep alive is greater
> than the occasional connection creation then the user can disable the reuse
> option.
> b) Creating a new session for each invocation is not optimal. Since the
> context hierarchy determines the scope of services and is independent of the
> transport session it's ok to reuse a JMS session underneath where ever it
> makes sense. If we introduce some thing similar to scope="transport-session"
> in HTTP for JMS, then we can allow users to directly use the underlying JMS
> transport similar to the way HTTP session is used.
> c) We can make the transacted property configurable. By default it will be
> false.
> <http://?auth=DQAAAHcAAABRNsIxA9tiVL3uczzey-x8FmU4gCUONPWKQAnlvhxhlFsCgDWBe2vo5cADP4RK1n0C-wf599ttpb3KuVGEQ1juQ4qqo7J7q47y0qAH12dW5DBAfbWjNSE-kzSN7uva1VddYFgwsvDPJHEKd2xLegIlVRPoMUsCpGd8rccaRUkjtg&shva=1>
> Ex: <parameter name="transport.jms.SessionTransacted">true</parameter>
> d) We need to expose the JMS session. Can we put the JMS session somewhere
> in the context hierarchy?
> I also see a getSessionContext in TransportListener interface, However
> SessionContext is written with HTTP in mind and is not generic enough.
> If we put it in the content hierarchy then the service author can retrieve
> it and call commit, rollback etc.
> e) We can create an XASession  instead of a normal session based on
> configuration, provided the JMS provider supports it.
> Ex. <parameter name="transport.jms.XASession">true</parameter>
> Comments are very much appreciated.
> Regards,
> Rajith
> On 9/4/07, Maciej Szefler <> wrote:
> >
> > Hi,
> >
> > I've been unable to find anything on the topic in Nabble, so I thought
> > I'd ping you all, and Asankha in particular regarding transactions in the
> > JMS transport implementation.
> > In ODE we'd like to be able to consume/send messages through AXIS' JMS
> > transport. That in itself is not a problem. However, we'd like the
> > send/receive to be in enrolled in a JTA transaction. Any pointers on how
> > this can be done?
> >
> > -Maciej
> >

View raw message