Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: "Johan Hoogenboezem" <hoogenbj@worldonline.co.za>
To: "'Kathey Marsden'" <kmarsdenderby@sbcglobal.net>
Cc: "'Derby Discussion'" <derby-user@db.apache.org>
Subject: RE: Derby XA, Hibernate 2.1.6,
 WebSphere 5.1 - Server returned XAER_NOTA at commit time
Date: Wed, 19 Oct 2005 06:35:09 +0200
Message-ID: <001601c5d466$7cd51820$d80515ac@rmbprivatebank.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <4353CADB.2080205@sbcglobal.net>

Thank you for your contribution. Especially the links. Stanley suggested =
I
try WAS 6 as apparently that works with Derby and XA. The tracing I
mentioned was the WAS tracing. I'll certainly try the Derby tracing too. =
I
agree it would be ideal to reproduce the error using Derby only. =
However, I
should mention I found no errors with WAS and Derby and XA as long as =
the
distributed transaction spanned databases only. For example, I =
successfully
committed and rolled back changes across two Derby databases in one
transaction. The error appears when one of the XA partners is JMS =
(WebSphere
MQ). Before you jump to conclusions, it works fine with DB2 and MaxDB, =
so it
seems as if WebSphere and/or WebSphere MQ are not at fault here.

Johan

-----Original Message-----
From: Kathey Marsden [mailto:kmarsdenderby@sbcglobal.net]=20
Sent: Monday, October 17, 2005 6:02 PM
To: Derby Discussion
Cc: 'Stanley Bradbury'
Subject: Re: Derby XA, Hibernate 2.1.6, WebSphere 5.1 - Server returned
XAER_NOTA at commit time


Johan Hoogenboezem wrote:

>Hi Stanley
>1. I will try to initiate a support case, but in my experience they =
drag
>their feet if they think the problem does not lie with WAS. They are =
also
>very likely to tell me to move to WAS 6.
>2. Like I said before, the trace logs are meaningless to me. And you =
are
>mistaken about the cleanup happening before XAERR_NOTA. Look at my =
first
>email.
>3. I'll try to get hold of WAS 6. I won't be able to pursue this avenue =
if
>it cannot co-exist with WAS 5, since it takes me more than a day to set =
up
>everything we require in WAS 5.
> =20
>
I haven't been following this thread, but  I don' think the Derby client
driver is shipped with WAS 6, and I could be wrong but I  don't think
there is a released  version of WAS  that includes the client driver, so
you are a bit of a trail blazer here.  That said,  if there is a client
XA bug it would be really good to track it down.  Probably the best bet
is for you to try to get a reproducible case that includes just Derby=20
that you can submit in Jira. . One thing  that might help you here is=20
the client tracing.  You can turn this on by using the setTraceFile
method on the ClientDataSource. If these are the tracelogs that you
talked about being meaningless to you, then please take a closer look
and come up with some specific quetsions about the tracing and I am sure
folks here on the list would be happy to answer your questions.  The
tracing is documented at:
http://db.apache.org/derby/docs/10.1/adminguide/cadminappsclienttracing.h=
tml
.
You could turn off  TRACE_PROTOCOL_FLOWS to reduce the trace volume of
the trace output and make it more manageable.

If you figure out the problem sequence of XA calls you can either write
a standalone java program or use the internal ij xa scripting language
that is used for the xa tests to write a reproducible case that you can
submit.

Good XA references if you are new to XA are:

The Sun Java Transaction API specification
http://java.sun.com/products/jta/index.html

The XA+ specification.
http://www.opengroup.org/publications/catalog/s423.htm


Kathey