Return-Path: 
 <commons-dev-return-79946-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 92495 invoked from network); 17 Nov 2005 23:35:22 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Nov 2005 23:35:22 -0000
Received: (qmail 74960 invoked by uid 500); 17 Nov 2005 23:35:19 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 74905 invoked by uid 500); 17 Nov 2005 23:35:19 -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 74894 invoked by uid 99); 17 Nov 2005 23:35:19 -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 15:35:19 -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 15:36:53 -0800
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EctEW-0007lM-MV
	for commons-dev@jakarta.apache.org; Fri, 18 Nov 2005 00:32:00 +0100
Received: from p549D42F1.dip0.t-ipconnect.de ([84.157.66.241])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <commons-dev@jakarta.apache.org>; Fri, 18 Nov 2005 00:32:00 +0100
Received: from joerg.heinicke by p549D42F1.dip0.t-ipconnect.de with local
 (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <commons-dev@jakarta.apache.org>; Fri, 18 Nov 2005 00:32:00 +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 23:31:02 +0000 (UTC)
Lines: 35
Message-ID: <loom.20051118T002234-338@post.gmane.org>
References: <loom.20051117T093442-815@post.gmane.org>
  <9da4f4520511170344s4d3cb5e7l@mail.gmail.com>
  <loom.20051117T133507-35@post.gmane.org>
 <9da4f4520511171502g37821092x@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: 84.157.66.241 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.12) Gecko/20050915)
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:

> Hmmm. I do not understand you either.

:)

> I have certainly read the XA spec, but - of course - am not entirely sure that
> my implementation is free of errors.

I did not know that it was you implementing it. And about the errors: that's
what I want to find out. Interpreting the spec is not that easy IMO, it is
really database specific and talks about "connection's close" method: Huh? Is it
about JTA or JDBC? Where is a connection in JTA.

> Active and suspended contexts are of course shared by the XA resource,
> why should it be local to a thread then?

My problem is that the contexts are specific to an XAResource *instance*. But is
it not possible to have more than one instance accessing one resource manager
from one thread? This is what my example with the two components was about. If
you use JNDI (standard in EJB 2.x) for looking up your XAResource you get a new
instance of XAResource for each lookup, so one for both components. This is why
I think the contexts must be made known to the thread (hence ThreadLocal), not
only to the instance.

> Maybe the misunderstanding is the active transaction branch which is
> associated to a specific thread. That's why it is a thread local. This
> means if there is a tx associated to a thead it will be stored there.

No I think, that is clear. It is only difficult to control if you allow multiple
XAResource instances per thread - which is allowed from my understanding.

Hope it's getting clearer where my actual problem is.

Jörg


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