I was spending some time investigating how to fix the jdbc driver to deal with the autocommit functionality in 7.3. I am trying to come up with a way of using 'set autocommit = on/off' as a way of implementing the jdbc symantics for autocommit. The current code just inserts a 'begin' after every commit or rollback when autocommit is turned off in jdbc.
I can continue to use the old way and just issue a 'set autocommit = on' at connection initialization, but I wanted to investigate if using 'set autocommit = off' would be a better implementation.
The problem I am having is finding a way to turn autocommit on or off without generating warning messages, or without having the change accidentally rolled back later.
Below is the current behavior (based on a fresh pull from cvs this morning):
Key: ACon = autocommit on
ACoff = autocommit off
NIT = not in transaction
IT = in transaction
IT* = in transaction where a rollback will change autocommit state
Current State Action End State
ACon and NIT set ACon ACon and NIT
set ACoff ACoff and IT*
ACon and IT set ACon ACon and IT
set ACoff ACoff and IT*
ACon and IT* set ACon ACon and IT*
set ACoff ACoff and IT
ACoff and NIT set ACon ACon and NIT
set ACoff ACoff and IT
ACoff and IT set ACon ACon and IT*
set ACoff ACoff and IT
ACoff and IT* set ACon ACon and IT
set ACoff ACoff and IT*
There are two conclusions I have drawn from this:
1) Without the ability for the client to know the current transaction state it isn't feasible to use set autocommit = on/off in the client. There will either end up being spurious warning messages about transaction already in process or no transaction in process, or situations where a subsequent rollback can undo the change. So I will stay with the current functionality in the jdbc driver until the FE/BE protocol provides access to the transaction status.
2) In one place the current functionality doesn't make sense (at least to me).
ACon and NIT set ACoff ACoff and IT*
If I am running in autocommit mode and I issue a command I expect that command to be committed. But that is not the case here. I would have expected the result to be: ACoff and NIT
thanks,
--Barry
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
