PATCH - watch transaction state and improve transaction handling - Mailing list pgsql-jdbc

From Chris Smith
Subject PATCH - watch transaction state and improve transaction handling
Date
Msg-id 02d101c3f3e2$7df87820$6f00000a@KYA
Whole thread Raw
List pgsql-jdbc
The attached patch to current CVS does the following:

    * Keeps track of the current transaction state.

    * Prevents starting a new transaction until actually required.

    * Causes all activity in a connection to share a single instance of
      QueryExecutor, as per Oliver's suggestion.  I did this in
      anticipation of it's helping out as I refactor QueryExecutor later.

    * Updates some aging comments (specifically, org.postgresql.Connection
      changes to org.postgresql.PGConnection).

This patch removes the 7.0 compatibility code for setting the transaction
isolation level at the beginning of each transaction.  I did that because it's
now QueryExecutor that starts new transactions rather than
AbstractJdbc1Connection, and there was no obvious place for the code.  I can
put it back in if that's the consensus.

Also, I still need to improve the search code that looks for
transaction-modifying code (commit, rollback, begin, etc) in v2 protocol SQL
that's sent by the user.  However, since this is not detected at all in the
current driver, I saw no reason to delay submitting the patch.

The current v2-protocol compatibility code for tracking the transaction state
handles BEGIN, START TRANSACTION, COMMIT, END, ROLLBACK, and ABORT, but only
if they are at the beginning of an SQL statement.  Does anyone know of other
commands that affect transactions and aren't in that list?  I found numerous
sources saying that -- unlike some other databases such as Oracle --
PostgreSQL does *not* automatically commit a transaction upon finding a DDL
command, but what exactly is going on with TRUNCATE TABLE prior to 7.3?  It's
described as not being able to be part of a transaction, so does that end your
current transaction?

(Note, I haven't yet completed some of the changes I've been discussing on the
list.  In particular, I still need to refactor QueryExecutor to migrate
protocol-specific code into different classes.  That's NOT in this patch.)

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Attachment

pgsql-jdbc by date:

Previous
From: Barry Lind
Date:
Subject: Re: A few more questions
Next
From: Warren Little
Date:
Subject: idle in transaction