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: 384FF823.93EBC358@exoffice.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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.

arkin

>
> 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
CTO http://www.exoffice.com
Exoffice, The ExoLab Company tel: (650) 259-9796

In response to

Browse pgsql-hackers by date

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

Browse pgsql-interfaces by date

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