Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43E3C765.9070204@amberpoint.com>
Date: Fri, 03 Feb 2006 13:13:09 -0800
From: Bryan Pendleton <bpendleton@amberpoint.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Updated: (DERBY-898) setAutoCommit(false) is not working
 properly for local connection with ClientXADataSource
References: <1705812163.1138987685686.JavaMail.jira@ajax.apache.org>
In-Reply-To: <1705812163.1138987685686.JavaMail.jira@ajax.apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> The problem in this case was that the  server side connection was  set to autocommit true. 
 > Even when the client has autocommit on, the server side connection should be autocommit
 > false and let the client drive the commits.

Hi Kathey,

I wonder if you could take a moment and expand on this idea a bit, because when
I first read it, I was surprised.

My first reaction when I saw DERBY-898 was to expect that the autocommit state
on the server and the client ought to match, and that when the autocommit state
on the client was changed, that change would be propagated to the server.

Thus, I expected to see you changing the client so that when setAutoCommit(false)
was called on the client, a message was sent to the server to turn autocommit
off on the server side.

Is this something specific to XA distributed transactions, or is it just a
fundamental aspect of how the Network Server behaves that all transaction
control should be performed by the client?

thanks,

bryan