PATCH - watch transaction state and improve transaction handling
От | Chris Smith |
---|---|
Тема | PATCH - watch transaction state and improve transaction handling |
Дата | |
Msg-id | 02d101c3f3e2$7df87820$6f00000a@KYA обсуждение исходный текст |
Список | 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
Вложения
В списке pgsql-jdbc по дате отправления: