Kathey Marsden <[EMAIL PROTECTED]> 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
piggybacked)
- 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
