JMS transacted session problem

[Anamitra]

Hi All
I am trying to use the Session TX in WLS 7.0 sp3 on win 2k platform. I am facing
this peculiar problem and not able to figure out if something I am doing wrong
OR I have hit a bug in WLS.

The code below uses my custom class to get a cached handle of the QueueConnection
for the QueueConnectionFacotry [JNDI name==MicConstants.JMS_QUEUE_CONNECTION_FACTORY].

After that all its trying to do is create a transacted session [not a JTA TX]
and create a sender and write 4 messages in the same TX to the Queue. It writes
the messages perfectly - but at the commit time it gives the following exception:

17 Oct 2003 15:46:56:800 [ERROR] Error Initializing MicService:No transaction
weblogic.jms.common.IllegalStateException: No transaction
at weblogic.jms.client.JMSXASession.commit(JMSXASession.java:59)
at psdi.iface.mic.MicService.init(MicService.java:259)
at psdi.server.ServiceCoordinator$ServiceStartThread.run(ServiceCoordina
tor.java:307)

The code is attached below. Is this a bug OR I am doing something wrong?

---------------------------CODE----------------------------------------
javax.jms.QueueConnection qcon = JMSConnectionStore.getInstance().getQueueConnection(MicConstants.JMS_QUEUE_CONNECTION_FACTORY);

javax.jms.QueueSession qs = qcon.createQueueSession(true,javax.jms.Session.AUTO_ACKNOWLEDGE);
javax.jms.QueueSender qsender = qs.createSender((javax.jms.Queue)JMSConfig.getInstance().getDestination("testqueue"));
qsender.send(qs.createTextMessage("hello"), javax.jms.DeliveryMode.PERSISTENT,
4, 0);
qsender.send(qs.createTextMessage("hello1"), javax.jms.DeliveryMode.PERSISTENT,
4, 0);
qsender.send(qs.createTextMessage("hello2"), javax.jms.DeliveryMode.PERSISTENT,
4, 0);
qsender.send(qs.createTextMessage("hello3"), javax.jms.DeliveryMode.PERSISTENT,
4, 0);
qs.commit();//Exception happens here!
-----------------------------------------------------------------------------------------

Any input is appreciated.

thanks
Anamitra

[Anamitra]

[Tom Barnes]

Hi Anamitra,

How are you ending up with a JMSXASession, rather
than a JMSSession, in the
first place? I think XAConnections ignore the "transacted"
flag of createSession by definition, which would cause the exception
you are getting. I wonder if
your cached QueueConnection is actually an
XAQueueConnection, probably created by
calling "connectionFactory.createXAQueueConnection"
instead of "connectionFactory.createQueueConnection".

Note that WL 8.1 has built-in pooling, you may
wish to look into that sometime in the future.

Tom

[Anamitra]

Hi Tom
thanks for that. I saw that I had the "XAConnection Factory Enabled" checked in
the console for my ConnectionFactory definition. See here is the requirement.
We do want to support both JTA and Session TX - we have a framework build around
JMS to do that. Its as easy as just flipping the TX attribute to Session or JTA
mode in our framework. Also we use the same ConnectionFactory for MDB which uses
[container managed TX] JTA and also the same connection factory.
So is it possible for us to use just "User Transactions Enabled" feature and use
that same connectiofactory for both JTA and session TX?
Why is the XA needed then?

thanks
Anamitra

[Tom Barnes]

Hi Anamitra,

My suspicion is that you pooled an XA connection rather
than a regular connection. In WebLogic, both are
XA (transaction) capable. The difference is that
the former ihas more restrictive semantics due
to requirements in the JMS standard - an XA connection
must not support transacted sessions by definition (
so it ignores the transacted flag). It looks
like you are attempting to use an XA connection to create
your transacted session - which won't work.

The solution is to set "UserTransactionsEnabled"
as you have already done, and create the queue connection
via "createQueueConnection" rather than
"createXAQueueConnection". The former
will support both user transactions
and transacted session "local" transactions.

I recommend reading the JMS FAQ and
the transaction chapter of the JMS programmer's
guide.

Note that using the same CF for multiple
purposes has performance implications
as the CF target's also determine connection
routing behavior (see the JMS Performance Guide).

Note that a custom CF for an MDB should
1) have user transactions enabled
2) have acknowledge mode set to "acknowledge-before"
It is not common to need a custom CF for an MDB.

Tom

[Tom Barnes]

Hi Anamira,

My last answer was too long (and wandered
too much). OK, here's the
short of it: just flip switch
number one to true, "User Transactions Enabled".
You don't want xaconnections, which, by
definition, ignore the user-transaction
flag on createSession.

Here is where my (and your) confusion came from.
Switch number two:
"XAConnectionFactory Enabled"
returns an XAConnection factory, but
calling xafactory.getConnection does NOT
return an xaconnection, it simply returns
a connection - which is what you want.
Normally you need to call
xaFactory.createXAConnection to actually
get an xaconnection. Makes sense? But,
(there is always a but),

(1) There is a bug in a couple
of the 7.1SPs where calling
xafactory.createConnection returns
an xaconnection. (This is
what some other vendors do, and the
person who put in this bug didn't
realize that it could cause pain.)

(2) If "xa server" enabled on the CF
then CF calls to getConnection always
return xaconnection (you don't want)
when it is invoked locally
by a co-located application.

And again, note that re-using the same
CF for multiple uses is problematic. The
targets of a CF have implications for
connection routing.

Tom

P.S. The three flags are simplified down
to a single flag in 8.1. (Thankfully)

[Anamitra]

Hi Tom
thanks for the detailed reply. I never called getXAConnection on the connectionfactory
handle - I allways called the getConnetion() .
I had the "XAConnectionFactory Enabled" to true and also the "Server Side XA Enabled"
to true - so per ur mail I would be all set if I set the "Server Side XA Enabled"
to false and hopefully I dont have the buggy sp [I am on sp3]. So let me give
it a try and I will let you know.

[Anamitra]

Hi Tom
I guess I hit the sp bug [its seems to be there in sp3]. I flipped the "Server
Side XA Enabled" to false and tried and it gave me the same error. Then I flipped
the "XAConnection Factory Enabled" false and then it worked. Is there any advantage
of keeping the latter to true?

[Tom Barnes]

Anamitra wrote:

> Hi Tom
> I guess I hit the sp bug [its seems to be there in sp3]. I flipped the "Server
> Side XA Enabled" to false and tried and it gave me the same error. Then I flipped
> the "XAConnection Factory Enabled" false and then it worked. Is there any advantage
> of keeping the latter to true?

No. Unless you are using a transaction monitor other than WebLogic's
to begin your transactions, in which case you need to register
the WL JMS session's resource directly with the "foreign" TM
and so would need the xaconnection.getXAResource() method.
(Pretty unlikely) Otherwise, you don't need xaconnections.

<rant>

Arguably, the whole purpose of the JMS XA APIs is
to supply a "connection.getXAResource()" call for registering JMS
with a transaction monitor. I personally think it was
overkill to specify a set of duplicate interfaces to accomplish
this, witness the problems it caused you.

And sadly, even the XA interfaces don't accomplish
their main purpose well. But that's another rant.

</rant>

[Anamitra]

Hi Tom
I am seeing a strange behaviour after turning off both the checkboxes related
to XA. My MDB no more picks up messages from the queue. So I went to the "Monitor..."
and saw that there are 0 consumers created for that Queue ie the server didnt
create a MDB instance. I shut down the server and check the "XA Connection Factory
Enabled" to true and it immediately starts picking up the messages!. One more
thing here is - I am still using the same connection factory for all my consumers
- [the thread pull guy and the MDB] - but I have only this MDB as the consumer
for this queue. So it seems the XA Connection Facotry Enabled has an effect on
the MDB [I am using the CMT for the MDB ie its server controlled].
Is this a bug - I am on sp3 7.0.?

[Tom Barnes]

Hi Anamatra,

I didn't anticipate that, but I think what is happening is
that the MDB is checking for XA for all vendors even
though it doesn't actually need to check for WL. This is not
really a bug so much as an unanticipated use of the MDB. As
you surmised, you will need to create a different connection
factory for the MDB that has the XA flag - my bet is that there is an
error message in log that already says the same thing. Anyhow, the
default MDB connection factory usually suffices - so you might
just not want to specify a CF for the MDB at all.

Tom