RE: [INTERFACES] Transaction support in 6.5.3/JDBC - Mailing list pgsql-hackers

From Peter Mount
Subject RE: [INTERFACES] Transaction support in 6.5.3/JDBC
Date
Msg-id 1B3D5E532D18D311861A00600865478C70BF64@exchange1.nt.maidstone.gov.uk
Whole thread Raw
List pgsql-hackers
-----Original Message-----
From: Assaf Arkin [mailto:arkin@exoffice.com]
Sent: Thursday, December 09, 1999 6:52 PM
To: Peter Mount
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC


The version I have sends requests protocol 1.0, once I changed that to
protocol 2.0, I got the pid/key. I also got the read-for-query response,
so that works fine for detecting when the BE is unable to process
further requests (for whatever reason).

PM: Eeek, this will break, as current sources already do this (I still
don't know why 6.5.3 didn't go out with those patches).

I've implemented the setTransactionIsolation method, that also works
fine. According to the specs only two levels are supported read
committed and serializable, and serializable is mistakingly spelled
"SERIALIZED".

PM: Already done, should have been in 6.5.3 :-(

I couldn't find any indication that PostgreSQL supports read-only
transactions, so either setReadOnly should throw an not-supported
exception, or getReadOnly should always return false. The current
behavior is to use a boolean which is not reflected in the DB.


I have another question, that is how can we synchronize our code bases.

For the minor changes I did to the JDBC layer I will simply send you the
modified sources.

PM: Currently its best to send direct to me, rather than to the patches
list. This is because the changes I'm making for 7.0 is very extensive,
and it would be safer for me to apply them manually. Also, it seems that
6.5.3 didn't pick up a lot of the patches I committed (but are in the
CVS). The protocol version is definitely one, as was some of the
transaction stuff.

For the JDBC 2.0 standard extensions stuff, I'm using a very generic
implementation that was developed independently of (but tested with)
PostgreSQL. The exact same code base exists in a different package
(txm.jdbc.xa) and can be put on top of any JDBC driver. It works better,
though, if the JDBC driver implements the TwoPhaseConnection interface.

Right now, anytime a change happens to txm.jdbc.xa I simply copy the
files and change the package to postgresql.xa. I would like to see these
files distributed as part of the PostgreSQL driver, but I also don't
want to get a conflict where updates to one code base are not reflected
in the other.

PM: What copyright do they have? I'm cc'ing the hackers list, as it's
one area we have to be careful of, and the others have more
experience/feelings on this subject.

Peter

> PM: In theory 6.5.3 should be requesting the current protocol (I
> remember the patch being submitted to me as part of another fix).
> However, I haven't (yet) had chance to look at it yet - hence not
> knowing about the security key. The bit I want to add is for JDBC2,
> ResultSet would by default use a cursor, and if it's closed while a
read
> is in effect, it would send cancel to the backend.
> 
> Peter
> 
>                         regards, tom lane
> 
> ************
> 
> ************

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


pgsql-hackers by date:

Previous
From: Peter Mount
Date:
Subject: RE: [INTERFACES] Transaction support in 6.5.3/JDBC
Next
From: Peter Mount
Date:
Subject: RE: [HACKERS] 6.6 release