Sender: arkin@arkin.exoffice.com
Message-ID: <384EB44E.DCDEF1E9@exoffice.com>
Date: Wed, 08 Dec 1999 11:41:02 -0800
From: Assaf Arkin <arkin@exoffice.com>
Organization: Exoffice
MIME-Version: 1.0
To: Peter Mount <petermount@it.maidstone.gov.uk>
CC: pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC
References: 
 <1B3D5E532D18D311861A00600865478C70BF1A@exchange1.nt.maidstone.gov.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> PM: JDBC based code should never issue begin/commit/rollback commands,
> and should use the similarly named methods in Connection. This is
> because a JDBC driver could be issuing these statements internally, and
> it would be confused. With our driver, you could currently get away with
> it, but it's not guaranteed to stay that way.

Inside a transaction, the application should not even use
commit/rollback on the JDBC connection, only through the transaction
monitor API. This is easy to solve, I simply return a ClientConnection
wrapper that prevents that. But someone can still send a commit/rollback
statement directly through the JDBC driver.

What I'm more afraid of is some operation that will cause a
commit/rollback to occur, e.g. a failed update, a trigger or stored
procedure.


> PM: Hmmm, in theory if a transaction is in a dead state (ie: an SQL
> statement failed, so anything else is ignored until the rollback), there
> should be a message in the notify queue. Our JDBC driver keeps these in
> the warnings queue, so you could read them prior to calling commit()
> yourself.

Thanks I'll try to look that out.


I've minimized all the special requirements I need from the driver to
three methods calls:

1. enbleSQLTransactions -- prevents a commit/rollback from being
executed directly in SQL; you can never be too careful ;-)

2. prepare -- should return false if the transaction is read-only, true
if it will commit, throw an exception if it will rollback

3. isCriticalError -- should tell me if a critical error occured in the
connection and the connection is no longer useable

How do I detect no. 3? Is there are certain range of error codes, should
I just look at certain PSQLExceptions as being critial (e.g. all I/O
related errors)?

arkin

> 
> arkin
> 
> --
> ____________________________________________________________
> Assaf Arkin                               arkin@exoffice.com
> CTO                                  http://www.exoffice.com
> Exoffice, The ExoLab Company             tel: (650) 259-9796
> 
> ************
> 
> ************

-- 
____________________________________________________________
Assaf Arkin                               arkin@exoffice.com
CTO                                  http://www.exoffice.com
Exoffice, The ExoLab Company             tel: (650) 259-9796