Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Transaction support in 6.5.3/JDBC

From: Assaf Arkin <arkin(at)exoffice(dot)com>
To: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
Cc: pgsql-interfaces(at)hub(dot)org, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC
Date: 1999-12-09 18:42:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
> PM: I wonder if we can get this functionality in the backend's parser -
> ie, for the API interfaces, they can set a variable on startup that
> disables begin, commit and rollback, then when they need to use them, it
> can then either temporarily clear the variable, or use a prefix that
> forces the statement to work?
> PM: enableSQLTransactions can then act immediately above this
> functionality.

That's what I was hoping for.

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

Works fine now that I've added a check for *ABORT STATUS*.

> 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)?
> PM: Don't rely on the text returned from PSQLException to be in English.
> We are pretty unique in that the driver will return an error message in
> the language defined by the locale of the client (also depends on if we
> have translated the errors into that language). What I could to is add a
> method to PSQLException that returns the original id of the Exception,
> and another to return the arguments supplied. That may make your code
> more portable.

I'm not looking into the messages, I know their language dependent. I
even added two or three new error messages, but only in English.

I'm looking for either specific error codes, range of error codes, or
some class extending PSQLException that will just indicate that this
connection is no longer useful. For example, if an I/O error occurs,
there's no ReadyForQuery reply, there's garbled response, etc.


> Peter
> --
> Peter Mount
> Enterprise Support
> Maidstone Borough Council
> Any views stated are my own, and not those of Maidstone Borough Council.
> ************

Assaf Arkin                               arkin(at)exoffice(dot)com
Exoffice, The ExoLab Company             tel: (650) 259-9796

In response to

pgsql-hackers by date

Next:From: Jan WieckDate: 1999-12-09 19:43:17
Subject: Weired FK problem
Previous:From: Don BaccusDate: 1999-12-09 16:00:50
Subject: check contraints incorrectly reject "null"

pgsql-interfaces by date

Next:From: Adolfo DiazDate: 1999-12-09 20:14:57
Subject: Apache+PostgreSQL+PHP3
Previous:From: Assaf ArkinDate: 1999-12-09 18:14:16
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group