Re: [JDBC] Read transactions don't work on 7.0.x db's 3rd attempt
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer Sent: September 4, 2001 1:21 PM To: [EMAIL PROTECTED] Subject: Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch Here is a revised patch with Barry's suggestions implemented Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch
Dave,
There is a bug in this patch. In the rollback case, you have:
! ExecSQL(rollback; begin+getIsolationLevelSQL());
You are missing a semicolon after the begin.
thanks,
--Barry
Dave Cramer wrote:
Here is a revised patch with Barry's suggestions implemented
Dave
Index: Connection.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/Connection.java,v
retrieving revision 1.26
diff -c -r1.26 Connection.java
*** Connection.java 2001/08/24 16:50:12 1.26
--- Connection.java 2001/09/04 17:21:29
***
*** 906,912
if (autoCommit)
ExecSQL(end);
else {
! ExecSQL(begin; + getIsolationLevelSQL());
}
this.autoCommit = autoCommit;
}
--- 906,917
if (autoCommit)
ExecSQL(end);
else {
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(begin;+getIsolationLevelSQL());
! }else{
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
this.autoCommit = autoCommit;
}
***
*** 935,941
public void commit() throws SQLException {
if (autoCommit)
return;
! ExecSQL(commit; begin; + getIsolationLevelSQL());
}
/**
--- 940,952
public void commit() throws SQLException {
if (autoCommit)
return;
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(commit;begin;+getIsolationLevelSQL());
! }else{
! ExecSQL(commit);
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
/**
***
*** 949,955
public void rollback() throws SQLException {
if (autoCommit)
return;
! ExecSQL(rollback; begin; + getIsolationLevelSQL());
}
/**
--- 960,972
public void rollback() throws SQLException {
if (autoCommit)
return;
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(rollback; begin+getIsolationLevelSQL());
! }else{
! ExecSQL(rollback);
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
/**
***
*** 1035,1055
if (haveMinimumServerVersion(7.1)) {
return ;
}
! String q = SET TRANSACTION ISOLATION LEVEL;
switch(isolationLevel) {
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
! q = q + READ COMMITTED;
break;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
! q = q + SERIALIZABLE;
break;
default:
throw new PSQLException(postgresql.con.isolevel,new
Integer(isolationLevel));
}
! return q;
}
/**
--- 1052,1072
if (haveMinimumServerVersion(7.1)) {
return ;
}
! StringBuffer sb = new StringBuffer(SET TRANSACTION ISOLATION LEVEL);
switch(isolationLevel) {
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
! sb.append( READ COMMITTED);
break;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
! sb.append( SERIALIZABLE);
break;
default:
throw new PSQLException(postgresql.con.isolevel,new
Integer(isolationLevel));
}
! return sb.toString();
}
/**
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Connection.patch
Content-Type:
text/plain
Content-Encoding:
7bit
Part 1.3
Content-Type:
text/plain
Content-Encoding:
binary
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Read transactions don't work on 7.0.x db's Disregard my other
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch
Here is a revised patch with Barry's suggestions implemented
Dave
Index: Connection.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/Connection.java,v
retrieving revision 1.26
diff -c -r1.26 Connection.java
*** Connection.java 2001/08/24 16:50:12 1.26
--- Connection.java 2001/09/04 17:21:29
***
*** 906,912
if (autoCommit)
ExecSQL(end);
else {
! ExecSQL(begin; + getIsolationLevelSQL());
}
this.autoCommit = autoCommit;
}
--- 906,917
if (autoCommit)
ExecSQL(end);
else {
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(begin;+getIsolationLevelSQL());
! }else{
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
this.autoCommit = autoCommit;
}
***
*** 935,941
public void commit() throws SQLException {
if (autoCommit)
return;
! ExecSQL(commit; begin; + getIsolationLevelSQL());
}
/**
--- 940,952
public void commit() throws SQLException {
if (autoCommit)
return;
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(commit;begin;+getIsolationLevelSQL());
! }else{
! ExecSQL(commit);
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
/**
***
*** 949,955
public void rollback() throws SQLException {
if (autoCommit)
return;
! ExecSQL(rollback; begin; + getIsolationLevelSQL());
}
/**
--- 960,972
public void rollback() throws SQLException {
if (autoCommit)
return;
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(rollback; begin+getIsolationLevelSQL());
! }else{
! ExecSQL(rollback);
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
/**
***
*** 1035,1055
if (haveMinimumServerVersion(7.1)) {
return ;
}
! String q = SET TRANSACTION ISOLATION LEVEL;
switch(isolationLevel) {
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
! q = q + READ COMMITTED;
break;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
! q = q + SERIALIZABLE;
break;
default:
throw new PSQLException(postgresql.con.isolevel,new
Integer(isolationLevel));
}
! return q;
}
/**
--- 1052,1072
if (haveMinimumServerVersion(7.1)) {
return ;
}
! StringBuffer sb = new StringBuffer(SET TRANSACTION ISOLATION LEVEL);
switch(isolationLevel) {
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
! sb.append( READ COMMITTED);
break;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
! sb.append( SERIALIZABLE);
break;
default:
throw new PSQLException(postgresql.con.isolevel,new
Integer(isolationLevel));
}
! return sb.toString();
}
/**
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [JDBC] Read transactions don't work on 7.0.x db's Disregard my other
Patch removed at Barry's request. The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Read transactions don't work on 7.0.x db's
Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Read transactions don't work on 7.0.x db's
From my POV there are two costs here: 1) The speed degradation by supporting multiple versions of postgres. I tend not to be too concerned by speed, and more concerned with ease of use. If speed really becomes an issue I can go into the code and remove the offending inefficiency caused by supporting multiple versions. 2) The barrier to entry by new jdbc, and postgres users trying to use postgres, and jdbc for the first time. If it doesn't work out of the box, then they will leave. I have a bias towards making it easier for people to use the software. However given the speed of server development. How far back are we going to support ? An argument can be made that since the software is free then there really is no reason not to upgrade. The biggest reason for me not to upgrade my server is reliability. What I have now works! I am hesitant to upgrade the server on a server which needs to run 24/7. That being said I am more likely to upgrade the jdbc driver, since: 1) it is really easy to back out the upgrade. 2) I have some ability to debug the jdbc driver and figure out what is going wrong. My ability to debug the postgres server is significantly less (approaching 0). So along with making it easier for new people to get the code up and running with a minimum of effort. I would like to take advantage of new jdbc features on older servers. My 2 cents worth Dave On Mon, 2001-09-03 at 19:46, Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Read transactions don't work on 7.0.x db's
I think it is important to support backward compatibility in code like the JDBC driver. It is often the case that code opperates in an environment where there may be servers at different release levels (production databases on 7.0, while dev databases are on 7.1). Thus I think that maintaining backward compatibility to the previous release is a minimum requirement. Begining with the 7.2 JDBC code it is now possible to support backward compatibility (i.e. methods now exist to conditionally execute code based on server version). That wasn't the case before now. In fact the 7.1 JDBC code is not backward compatible with 7.0 (although the incompatibilies are in areas that many users may not notice and thus for many it is backwardly compatible). I am not sure how far back to maintain backward compatibility. I think it is dependent on how often new server versions are released. In general I would not want to force a database user to upgrade more than once per year (since doing a dump/restore on a large database can be a large hastle). Therefore I would recommend that going forward the JDBC drivers support all back releases that where the latest release within the last year. For example since 7.1 came out in April 2001, this would mean supporting 7.0 until April 2002. And if 7.2 when production in October 2001, then 7.1 should be supported until October 2002. thanks, --Barry Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Read transactions don't work on 7.0.x db's
Dave,
The multiple statements in one call is there for performance reasons.
Please don't remove it entirely since it works fine in 7.1 and 7.2.
Instead your fix should be conditional based on server version:
if (autoCommit)
ExecSQL(end);
else {
ifMinumumServerVersion(7.1) {
ExecSQL(begin; + getIsolationLevelSQL());
} else {
ExecSQL(begin);
ExecSQL(getIsolationLevelSQL());
}
}
thanks,
--Barry
Dave Cramer wrote:
Here's a patch to fix the problem below
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer
Sent: August 30, 2001 8:51 PM
To: [EMAIL PROTECTED]
Subject: [JDBC] Read transactions don't work on 7.0.x db's
The following code fails on a 7.0 db, but works on a 7.1 db
It works fine with the 7.0 jar, but not with the latest code
I had a quick look and everything looks ok. I am going to keep looking
but I thought I would throw this out and see if anyone knows what is
going on
Dave
package test;
import java.sql.*;
/**
* Title:
* Description:
* Copyright:Copyright (c) 2001
* Company:
* @author
* @version 1.0
*/
public class TransactionSelect {
public TransactionSelect()
{
}
public static Connection getConnection( String url, String user,
String password)
{
try {
Class.forName(org.postgresql.Driver);
return java.sql.DriverManager.getConnection(url,user,password);
} catch(ClassNotFoundException ex) {
ex.printStackTrace(System.out);
} catch(SQLException ex) {
ex.printStackTrace(System.out);
}
return null;
}
public static void main(String[] args)
{
try{
Connection con =
getConnection(jdbc:postgresql://192.168.1.1/davec,davec,);
if (con == null){
throw new RuntimeException(no Connection);
}
con.setAutoCommit(false);
PreparedStatement pstmt = con.prepareStatement(select * from
categories );
ResultSet rs = pstmt.executeQuery();
con.commit();
con.close();
}catch (SQLException ex){
ex.printStackTrace(System.out);
}
}
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Connection.patch
Content-Type:
application/octet-stream
Content-Encoding:
quoted-printable
Part 1.3
Content-Type:
text/plain
Content-Encoding:
binary
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [JDBC] Read transactions don't work on 7.0.x db's Disregard my other patch
The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave Connection.patch ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[JDBC] Read transactions don't work on 7.0.x db's
The following code fails on a 7.0 db, but works on a 7.1 db
It works fine with the 7.0 jar, but not with the latest code
I had a quick look and everything looks ok. I am going to keep looking
but I thought I would throw this out and see if anyone knows what is
going on
Dave
package test;
import java.sql.*;
/**
* Title:
* Description:
* Copyright:Copyright (c) 2001
* Company:
* @author
* @version 1.0
*/
public class TransactionSelect {
public TransactionSelect()
{
}
public static Connection getConnection( String url, String user,
String password)
{
try {
Class.forName(org.postgresql.Driver);
return java.sql.DriverManager.getConnection(url,user,password);
} catch(ClassNotFoundException ex) {
ex.printStackTrace(System.out);
} catch(SQLException ex) {
ex.printStackTrace(System.out);
}
return null;
}
public static void main(String[] args)
{
try{
Connection con =
getConnection(jdbc:postgresql://192.168.1.1/davec,davec,);
if (con == null){
throw new RuntimeException(no Connection);
}
con.setAutoCommit(false);
PreparedStatement pstmt = con.prepareStatement(select * from
categories );
ResultSet rs = pstmt.executeQuery();
con.commit();
con.close();
}catch (SQLException ex){
ex.printStackTrace(System.out);
}
}
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
