JDBC driver does not support XA

Scott Bermon

unread,

Apr 23, 2001, 1:46:54 PM4/23/01

to

Working on WL5 to WL6 migration.

When I run the application, and a JMS message is sent to a
DurableSubscriber, WL6 has this to say:

....also; why does setting enableTwoPhaseCommit to true, force a JDBC driver
to participant in something it seemingly does support?

Scott Bermon

unread,

Apr 23, 2001, 1:50:40 PM4/23/01

to

When I set this:

Nothing deploys. Not even the console. WL6 starts, but there is nothing
there?

"Scott Bermon" <scott....@sitraka.com> wrote in message
news:3ae46ae3$1...@newsgroups.bea.com...

Stephen Felts

unread,

Apr 23, 2001, 3:19:11 PM4/23/01

to

WLS pre-6.0 used to get by with a one-phase commit if the JMS JDBC store and
the
SQL in the EJB used the same underlying database.
That is no longer true (see
http://developer.bea.com/docs/jmsfaq.jsp#_TOC137).
So now, you need to configure to allow for a two-phase commit - in
particular,
you need to configure the XA-compliant JDBC driver (that implements
XAResource)
for your EJB SQL access.
JMS still uses the non-XA compliant JDBC driver - it implements XA above the
JDBC interface (so it will work, even on a non-XA-compliant JDBC or
alternatively
using the new JMS file store feature).

"Scott Bermon" <scott....@sitraka.com> wrote in message
news:3ae46ae3$1...@newsgroups.bea.com...

Robert Patrick

unread,

Apr 24, 2001, 1:45:01 AM4/24/01

to

This seems like a bad idea... Why would you want to impose 2PC semantics
instead of allowing 1PC semantics in this special case?

Stephen Felts

unread,

Apr 24, 2001, 9:21:30 AM4/24/01

to

The goal was to allow for JMS to participate in 2PC using a JDBC store
with a database that didn't support 2PC (since many of them don't).
We couldn't have it both ways.
The WLS JMS interface appears as its own XAResource, independent
of the underlying JDBC interface.

"Robert Patrick" <rhpa...@attglobal.NOSPAM.net> wrote in message
news:3AE512DD...@attglobal.NOSPAM.net...

Scott Bermon

unread,

Apr 24, 2001, 10:27:20 AM4/24/01

to

When I add the 'EnableTwoPhaseCommit' attribute to the JDBCTxDataSource
element; Weblogic starts, but there is nothing there. The console, ejbs,
servlets, jsp; nothing gets deployed. It just says Weblogic started.

Enter password to boot WebLogic server:system
Starting WebLogic Server ....
<Apr 24, 2001 8:58:49 AM EDT> <Notice> <Management> <Loading configuration
file
.\config\myserver\config.xml ...>
log file: D:\bea\weblogic\.\myserver.log
<Apr 24, 2001 8:58:52 AM EDT> <Info> <Logging> <Only log messages of
severity "E
rror" or worse will be displayed in this window. This can be changed at
Admin Co
nsole> myserver> Servers> myserver> Logging> General> Stdout severity
threshold>

Here is the element from the config.xml file:

"Stephen Felts" <s...@bea.com> wrote in message
news:3ae4...@newsgroups.bea.com...

Stephen Felts

unread,

Apr 24, 2001, 12:09:32 PM4/24/01

to

You need to look at the log file to see what happened.

"Scott Bermon" <scott....@sitraka.com> wrote in message

news:3ae58d9e$1...@newsgroups.bea.com...

Robert Patrick

unread,

Apr 25, 2001, 9:02:12 AM4/25/01

to

Hmm... It seems to me that you could use a strategy pattern to expose either
the JMS XAResource or the JDBC driver's XAResource depending on the capabilities
of the JDBC driver.

I know at least one customer (that we have talked about previously) that will
not be happy to hear this...

Robert

Tim Ozor

unread,

Apr 26, 2001, 1:32:05 PM4/26/01

to

I'm also discouraged by this implementation strategy (which I may not
understand, so correct me if I mis-state something). Turning on two phase
commit is very expensive , especially if your application has been designed
to specifically use the same database in order to eliminate the need for two
phase commit. I know I can use a file store to get some of this performance
back, but I am still forced to enable two phase commit on the Tx DataSource
that my EJB(s) are using if this driver is XA complaint and if I my
application has EJB and JMS activity in the same transaction. Doesn't this
make my EJB access slower for transactional methods which initiate no JMS
activity?

Also as a point of clarification, if I have a non-XA compliant JDBC driver
configured as a Tx Data Source for EJB access, and a JMS file store for JMS
access, does the JMS XA resource manager act as the resource manager for
both when JMS and EJB activity occur in the same transaction? In this
configuration, I am not forced to enable two phase commit on the Tx Data
Source. However if a change the configuration to use an XA compliant JDBC
driver, then I am forced two turn on two phase commit in order to get EJB
and JMS activity to work in the same transaction (i.e. to avoid the error
message displayed in the original post). This leads me to believe that the
JDBC XA resource manager is expected to handle the EJB activity since JMS
sees it as an XA compliant JDBC driver.

Again, please correct any mis-statements in my above analysis. I am really
trying to avoid enabling two phase commit, but I also have JMS and EJB
activity in the same transaction. I also admit that I have not benchmarked
the performance boost of a JMS file store to understand if my overall two
phase commit performance concerns are valid. However, a one phase commit on
the same database connection (basically the 5.1 behavior) still seems like a
nice performance and functionality optimization if an application has been
designed to use a single data source for all transactional activity.

Tim Ozor (oz...@vignette.com)

"Robert Patrick" <rhpa...@attglobal.NOSPAM.net> wrote in message

news:3AE6CAD4...@attglobal.NOSPAM.net...

Zach

unread,

Apr 26, 2001, 2:11:54 PM4/26/01

to

If you are only using one resource manager, then there is
no two-phase commit, and you are not paying for two-phase
commit - this is a standard optimization. In the case of JMS
being backed by the same database used by your application
there are two resource managers. The database is one resource
manager and the JMS server is the other. If we are not the
resource manager then we don't know when the transaction
commits or rollsback since all that would go to the database.
That means we wouldn't know when to shift things around in
memory. The database triggers and queries required to
maintain state in that environment would far exceed the cost
of having the two resource managers.

You might even find that WL6 JMS using 2PC is faster than
WL5.1 JMS using 1PC.

_sjz.