Return-Path: 
 <commons-dev-return-79914-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 55906 invoked from network); 17 Nov 2005 13:00:33 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Nov 2005 13:00:33 -0000
Received: (qmail 53316 invoked by uid 500); 17 Nov 2005 13:00:30 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 53257 invoked by uid 500); 17 Nov 2005 13:00:30 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 53246 invoked by uid 99); 17 Nov 2005 13:00:29 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 05:00:29 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 05:02:03 -0800
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EcjKt-0008JO-Il
	for commons-dev@jakarta.apache.org; Thu, 17 Nov 2005 13:57:55 +0100
Received: from srvgw12.rauser-ag.com ([217.146.133.165])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <commons-dev@jakarta.apache.org>; Thu, 17 Nov 2005 13:57:55 +0100
Received: from joerg.heinicke by srvgw12.rauser-ag.com with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <commons-dev@jakarta.apache.org>; Thu, 17 Nov 2005 13:57:55 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: commons-dev@jakarta.apache.org
From: Joerg Heinicke <joerg.heinicke@gmx.de>
Subject: Re: [transaction] AbstractXAResource throws exception on TMJOIN
Date: Thu, 17 Nov 2005 12:54:31 +0000 (UTC)
Lines: 40
Message-ID: <loom.20051117T133507-35@post.gmane.org>
References: <loom.20051117T093442-815@post.gmane.org>
 <9da4f4520511170344s4d3cb5e7l@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 217.146.133.165 (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE;
 rv:1.7.12) Gecko/20050919 Firefox/1.0.7)
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:

> > there seems to be some inconsistency in the implementation of
> > AbstractXAResource regarding TMJOIN in the start() method. The first thing
> > that is checked for in this method is
> > "getCurrentlyActiveTransactionalResource() != null" and a XAException is
> > thrown if there is a currently active transactional resource (CATR). But IMO 
> > this is wrong for TMJOIN as you want to join a transaction, so
> > there must be a CATR.
> 
> A thread can only be part of at most one transaction at a time. If it
> already has an active transaction, joining another is an invalid
> operation.

Sorry, but I don't understand you here. If a thread can only have one
transaction, why is it not allowed to join this active one?

But re-reading the spec I came to the conclusion that the "CATR != null" check
is not the problem. In section 3.4.4 of the spec (you know it?) there is a table
about the correct XAResource to transaction association. And for both
start(NOFLAGS) and start(TMJOIN) the XAResource can only switch from "not
associated" to "associated" meaning that the null check is ok.

But as far as I understand the spec there can be multiple instances of
XAResource accessing the same resource manager (otherwise TMJOIN makes no sense,
and XAResource.isSameRM(XAResource) neither).
Example: Both component1 and component2 have a method requiring a transaction,
and component1 calls component2. Both lookup the same XAResource from JNDI
actually getting different instances of this XAResource. When component2 now
accesses the XAResource it actually *joins* the transaction.

This means that another aspect of AbstractXAResource is wrong: I already
mentioned createTransactionResource(Xid) for TMJOIN in the last mail. IMO it
must be getActiveTransactionalResource(Xid). This leads to another change to get
it working as the activeContexts would be empty of course: The both maps
suspendedContexts and activeContexts must be static ThreadLocal variables.

Regards,

Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org