Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42AF5EE4.4060506@sbcglobal.net>
Date: Tue, 14 Jun 2005 15:49:08 -0700
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Question about holdability and XA
References: <42AA006C.8010800@sbcglobal.net>
 <42AA01DE.3030001@debrunners.com>	 <42AA3553.10205@sbcglobal.net>
 <42AA49C6.3080805@debrunners.com>	 <42AA680A.6020801@sbcglobal.net>
	 <d9619e4a05061201375186b7ab@mail.gmail.com>
	 <42AC4E8B.4090004@sbcglobal.net> <d9619e4a050614144525737656@mail.gmail.com>
In-Reply-To: <d9619e4a050614144525737656@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Mamta Satoor wrote:

> Hi Kathey,
>  
> Just to summarize, the holdability table will look the same for
> EmbedConnection as well as BrokeredConnection.
>  
>                         Global Transaction                            
> Local Transaction
> JDK13    CLOSE_CURSORS_AT_COMMIT        conn holdability (Default
> HOLD_CURSORS_OVER_COMMIT)
> JDK14+   CLOSE_CURSORS_AT_COMMIT       conn holdability (Default
> HOLD_CURSORS_OVER_COMMIT)
>  
> A Connection object will have it's holdability set to default which is
> HOLD_CURSORS_OVER_COMMIT. When the connection joins a global
> transaction, the holdability will get switched internally to
> CLOSE_CURSORS_AT_COMMIT. When the connection leaves the global
> transaction and becomes part of local transaction, the holdability is
> restored to what it was before entering the global transaction. It
> works this way in both jdk13 and jdk14+. One thing to keep in mind is
> that PreparedStatement get the holdability from where they are
> prepared and not where they are executed, for instance,
> Start Local Transaction
> Connection holdability (default - HOLD_CURSORS_OVER_COMMIT)
> PreparedStatement (holdability will be HOLD_CURSORS_OVER_COMMIT)
> ResultSet from PreparedStatement will have holdability as
> HOLD_CURSORS_OVER_COMMIT
> Start Global Transaction
> Connection holdability switches to CLOSE_CURSORS_AT_COMMIT
> Another ResultSet from PreparedStatement will attempt to have the
> preparedStatement's holdability and that will cause exception because
> Global transactions do not support holdable cursors.
> Exit Global Transaction and become part of Local Transaction
> Connection holdability back to HOLD_CURSORS_OVER_COMMIT

Thanks Mamta for the summary.   Good to understand the intended
behviour  while trying to get the client holdability to match the server.

>  
> I have come across one bug with jdk13 though, where the holdability is
> not getting restored back to HOLD_CURSORS_OVER_COMMIT when the
> connection becomes part of local transaction after leaving global
> transaction. I will enter a JIRA entry for it and start working on it.

Of course this bug is probably why I am seeing xaSimplePostive.sql pass
for jdk131 with client #:), but great to have that mystery solved too.
.
Kathey