db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-898) setAutoCommit(false) is not working properly for local connection with ClientXADataSource
Date Fri, 03 Feb 2006 22:27:10 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> Bryan Pendleton wrote:
> > 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?
> >
> It is the same for all connections. The transactional control is
> performed by the client.
> The server side connection is always autocommit false, but  in
> XADatabase.java  it was not being set properly as it is in Database.java.
> I think that we could probably see a significant performance 
> improvement if autocommit is true if we switched to a different model
> and sent an EXCSQLSET command of some sort with setAutoCommit(),  This
> would be similar to Oyvind's implemetnation for setQueryTimeout.  Right
> now,  with autocommit true there is an extra round trip to the server
> with each statement, because the client has to send the statement
> followed by the commit. Of course we would need to take care to do the
> right thing for older clients.

Hi Kathey and Bryan,

I doubt that such a modification would improve the performance. The
client driver is already piggybacking the commit messages so the
number of round trips is not affected.

This might change a bit if my patch for DERBY-821 is accepted. Right
now, we have this situation:

  - ps.executeUpdate() needs one round trip (execute with commit

  - ps.executeQuery() needs one round trip, but you get an extra round
    trip to close the result set (commit is piggybacked on close)

With my patch for DERBY-821, nothing changes for
executeUpdate(). However, when using executeQuery(), you don't need a
round trip to close the result set. Instead, you need a round trip for
commit, since you don't have a message to piggyback it on. So in this
case autocommit on the server would be advantageous.

Knut Anders

View raw message