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: