Keeping track of the transaction state would be a lot of work.
Even a resultset has a lot of update* methods. (very dangerous for making mistakes)
What we can do is check Connection.isReadOnly() and do not rollback in that case. Then you can use one read-only pool and one read-write pool.
Would that help?
Maybe you can do some driver performance tests to time all those gettters/setting on Connection to find the best/worst methods to use?
-- Dirk
Richard Bielak wrote:
Hi,
We are using BasicDataSource for managing db connections to Postgresql (v7.3). By default our connections have autoCommit set to false
and we manage our transactions so that no connection is ever returned to the pool while transaction is active. In the Postgresql log we saw tons of messages:
Oct 20 08:12:19 flatiron postgres[12177]: [27558] WARNING: ROLLBACK: no transaction in progress
It appears that when a connection is returned to the pool and the autocommit is false, a "rollback()" is called on the connection.
Is there a way to turn this behavior off? Wouldn't it be better to keep track of whether transaction is in progress on and "rollback()" then?
Although the rollback is harmless it does create a performance issue - we have an extra database call each time a connection is put back in the pool.
Any suggestions wil be greatly appreciated.
...richie
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
