Re: [JDBC] JAVA vs PERL : PERL wins to postgreSQL
The obvious question is whether the PERL-script is also executing in one
transaction. If it is not, we're "cheating" setting autocommit off in the
JDBC-test app. (I did not look at the code, since I am not familiar with the
PGSQL's PERL-interface anyway.)
Peter
> -Original Message-
> From: Barry Lind [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 04, 2001 6:49 PM
> To: andy
> Cc: [EMAIL PROTECTED]
> Subject: Re: [JDBC] JAVA vs PERL : PERL wins to postgreSQL
>
>
> Andy,
>
> Thanks for the code. In looking at this there are two things
> that come
> to mind:
>
> 1) You probably should be running vacuum after the delete to
> clean up
> the table, but on a table this small, I doubt it will make any real
> difference.
>
> 2) Why have you set autocommit on? This should be much faster with
> autocommit off.
>
> Actually I just did a quick test of the two changes I
> mentioned above.
> The first (vacuum) doesn't make any noticable difference, however
> turning autocommit off causes the timings on my machine to go from 14
> seconds to 6 seconds. Better than 50% improvement.
>
> thanks,
> --Barry
>
>
> andy wrote:
> > To all those who responded ,
> > Thanks for your response,
> >
> > I have attached the test programs that I used in the form
> of text files. The
> > contents should be self evident. Please have a look and comment.
> >
> > I used j2sdk1.3.1 down load to linux machine from sun.com
> as my java platform
> > and
> > And perl, v5.6.0 built for i386-linux.
> > The PostgreSQL driver for perl came from www.perl.org
> > The postgreSQL driver in jdbc7.0-1.2.jar
> >
> >
> > Barry Lind wrote:
> >
> >
> >>Andy,
> >>
> >>I would be interesting in knowing what version you did this test on,
> >>what platform, and most importantly which JDK (and if the
> Sun JDK which
> >>JVM: classic, hotspot client, hotspot server).
> >>
> >>thanks,
> >>--Barry
> >>
> >>andy wrote:
> >>
> >>>Hi,
> >>>
> >>>I ran a few bench marks on JAVA writing to a postgreSQL
> table using and
> >>>found that for the same number of records added to the table as a
> >>>similar PERL routine the following results :
> >>> PERL 39 seconds : JAVA 45 Seconds.
> >>>In a similar experiment where PERL and JAVA did treir output to the
> >>>screen and not to a table,
> >>>
> >>>JAVA took 3 seconds and PERL 310 Seconds.
> >>>My conclusion is that the database driver to postgreSQL is
> still far
> >>>from efficient in the JAVA implementation.
> >>>
> >>>Both tests were run on the same computer.
> >>>
> >>>I would appreciate your comments and suggestions.
> >>>Andy Sewell
> >>>
> >>>
> >>>---(end of
> broadcast)---
> >>>TIP 5: Have you checked our extensive FAQ?
> >>>
> >>>http://www.postgresql.org/users-lounge/docs/faq.html
> >>>
> >>>
> >>>
> >>>
> >>>---
> -
> >>>
> >>>/*
> >>> Java bench mark against perl count to 100 000 000
> >>>*/
> >>>import java.io.*;
> >>>import java.util.*;
> >>>
> >>>public class lp{
> >>>
> >>> public lp() throws ClassNotFoundException,
> FileNotFoundException, IOException
> >>> {
> >>>int last = 1000;
> >>>
> >>> GregorianCalendar day = new GregorianCalendar();
> >>>String time = day.getTime().toString();
> >>> int k=0;
> >>> for (int i=0; i >>> for (int p=0; p {k=1+p;System.out.println(k);}
> >>> }
> >>>
> >>> GregorianCalendar day1 = new GregorianCalendar();
> >>> String time2 = day1.getTime().toString();
> >>> System.out.println(time);
> >>> System.out.println(time2 + "\n" + k);
> >>>
> >>>
> >>> }
> >>>
> >>>public static void main(String[] args) {
> >>> try {
> >>>lp test = new lp();
> >>> }
> >>> catch (Exception ex) {
> >>> System.err.println("Exception :" + ex);
> >>>ex.printStackTrace();
> >>> }
> >>>}
> >>>}
> >>>
> >>>
> >>>
> >>>---
> -
> >>>
> >>>/*
> >>> Java equivalent
> >>>*/
> >>>import java.io.*;
> >>>import java.sql.*;
> >>>import java.util.*;
> >>>
> >>>public class pg{
> >>> Connection conn;
> >>> Statement stmt;
> >>>
> >>> public pg() throws ClassNotFoundException,
> FileNotFoundException, IOException, SQLException
> >>> {
> >>> Class.forName("org.postgresql.Driver");
> >>>conn =
> DriverManager.getConnection("jdbc:postgresql:exkom", "andy", "");
> >>> conn.setAutoCommit(true);
> >>> stmt = conn.createStatement();
> >>>int last = 1;
> >>>int res = stmt.executeUpdate("delete from junk");
> >>>
> >>> GregorianCalendar day = new GregorianCalendar();
> >>>String time = day.getTime().toString();
> >>>
> >>> for (int i=0; i >>> // try {
> >>> res = stmt.executeUpdate("insert
Re: [JDBC] Patch for jdbc2 ResultSet.java
Joseph,
In looking at this patch it looks OK, except for the following change:
> ! if (index>=-rows.size())
> --- 725,737
> ! if (index > rows_size)
I haven't looked at the entire method, but the change you made seems
incorrect.
If you want this patch to be applied it should be sent to the
pgsql-patches mail list.
thanks,
--Barry
Joseph Shraibman wrote:
> Just some minor fixes to avoid duplicate function calls that were
> bugging me.
>
> If rows is garunteed not to change then we can store the size in a final
> class variable, but I wasn't sure I could assume that.
>
> *** ResultSet.java.origTue Sep 4 16:34:14 2001
> --- ResultSet.javaTue Sep 4 16:45:20 2001
> ***
> *** 134,140
> {
> //release resources held (memory for tuples)
> if(rows!=null) {
> - rows.setSize(0);
> rows=null;
> }
> }
> --- 134,139
> ***
> *** 709,716
> public int findColumn(String columnName) throws SQLException
> {
> int i;
> !
> ! for (i = 0 ; i < fields.length; ++i)
> if (fields[i].getName().equalsIgnoreCase(columnName))
> return (i+1);
> throw new PSQLException ("postgresql.res.colname",columnName);
> --- 708,715
> public int findColumn(String columnName) throws SQLException
> {
> int i;
> ! final int flen = fields.length;
> ! for (i = 0 ; i < flen; ++i)
> if (fields[i].getName().equalsIgnoreCase(columnName))
> return (i+1);
> throw new PSQLException ("postgresql.res.colname",columnName);
> ***
> *** 726,736
> if (index==0)
> throw new SQLException("Cannot move to index of 0");
>
> //if index<0, count from the end of the result set, but check
> //to be sure that it is not beyond the first index
> if (index<0)
> ! if (index>=-rows.size())
> ! internalIndex=rows.size()+index;
> else {
> beforeFirst();
> return false;
> --- 725,737
> if (index==0)
> throw new SQLException("Cannot move to index of 0");
>
> + final int rows_size = rows.size();
> +
> //if index<0, count from the end of the result set, but check
> //to be sure that it is not beyond the first index
> if (index<0)
> ! if (index > rows_size)
> ! internalIndex = rows_size+index;
> else {
> beforeFirst();
> return false;
> ***
> *** 739,745
> //must be the case that index>0,
> //find the correct place, assuming that
> //the index is not too large
> ! if (index<=rows.size())
> internalIndex = index-1;
> else {
> afterLast();
> --- 740,746
> //must be the case that index>0,
> //find the correct place, assuming that
> //the index is not too large
> ! if (index <= rows_size)
> internalIndex = index-1;
> else {
> afterLast();
> ***
> *** 753,760
>
> public void afterLast() throws SQLException
> {
> ! if (rows.size() > 0)
> ! current_row = rows.size();
> }
>
> public void beforeFirst() throws SQLException
> --- 754,762
>
> public void afterLast() throws SQLException
> {
> ! final int rows_size = rows.size();
> ! if (rows_size > 0)
> ! current_row = rows_size;
> }
>
> public void beforeFirst() throws SQLException
> ***
> *** 967,973
>
> public boolean isAfterLast() throws SQLException
> {
> ! return (current_row >= rows.size() && rows.size() > 0);
> }
>
> public boolean isBeforeFirst() throws SQLException
> --- 969,976
>
> public boolean isAfterLast() throws SQLException
> {
> ! final int rows_size = rows.size();
> ! return (current_row >= rows_size && rows_size > 0);
> }
>
> public boolean isBeforeFirst() throws SQLException
> ***
> *** 982,995
>
> public boolean isLast() throws SQLException
> {
> ! return (current_row == rows.size() -1 && rows.size() > 0);
> }
>
> public boolean last() throws SQLException
> {
> ! if (rows.size() <= 0)
> return false;
> ! current_row = rows.size() - 1;
> this_row = (byte [][])rows.elementAt(current_row);
> return true;
> }
> --- 985,1000
>
> public boolean isLast() throws SQLException
> {
> ! final int rows_size = rows.size();
> ! return (current_row == rows_size -1 && rows_size > 0);
> }
>
> public boolean last() throws SQLException
> {
> ! final int rows_size = rows.size();
> ! if (rows_size <= 0)
> return false;
> ! current_row = rows_size - 1;
> this_row = (byte [][])rows.elementAt(current_row);
> return true;
> }
> ***
> *** 1480,1483
> }
> }
>
Re: [JDBC] driver source code indentation
On Tue, 4 Sep 2001, Bruce Momjian wrote:
> Can people tak a look at that and see if they like it? I will work on
> astyle to find a format that matches the main code indenting.
>
> If you like it, I will indent just after we go beta.
Looks great!
I only noticed two things that I sort of disliked. Luckily this seems to
be the only differences between the example and the standard used in the C
sources! :) It's also the only differences between the example and Sun's
standard that I could see.
* Missing a space between "if" and "(".
* Missing a space after a type cast.
/Anders
_
A n d e r s B e n g t s s o n [EMAIL PROTECTED]
Stockholm, Sweden
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
What I have is a connection pool.
I initially grab 2 connections, one primary one secondary.
If the insert fails on the primary connection I try the
secondary, if it fails I simply delete the 2 I have and grab
2 more from the connection pool. After creating the new ones
I have never seen it fail the first few times which is what
leads me to believe that something in the connection itself is
getting corrupted over time. Note that each connection is a separate
process in the unix environment. I believe it is this process that
is getting corrupted note necessarily the java connection wrapper.
Of course this is all guess work right now. I'll let you know if I
come up with a better solution or are able to determine why
these connections act like they are getting corrupt.
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 5:42 AM
To: Missner, T. R.; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
follow-up question - you say that if you get one exception, you try the
insert with another connection...if that doesn't work you delete the
existing connections and get new ones...
i must be missing something - why wouldn't using the second connection
always work? if you get rid of the offending connection (the first one),
why does the second one have a problem? or am i confusing your connection
object with the actual connection?
thanks
chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 3:35 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is catch
the exception and try the insert again with another connection. If it still
fails I delete the connections I have and create new ones and the insert
ALWAYS works after that. So it appears to me that something is happening
to my connection object that is causing it to get corrupted to some extent.
Once a connection throws this exception it seems much more likely to do so
again which is why I am deleting connections and creating new ones if I have
2 failures back to back. This isn't the answer you are looking for but
I hoped it might help you think of other ways to troubleshoot your problem.
Since I put this work around in I have been able to run a very high rate
and haven't lost any data on the insert side. My guess is that these
Fastpath
transactions are very slow compared to non fastpath transactions and it
is easy to use a connection that hasn't finished what it is doing.
I even used a synchronized method to hopefully block on the connection
but this didn't fix the problem either. Must be some threading going on
in the connection class. I haven't had the time to go through the code
but I will at some point.
I know someone out there has some insight that could help.
t.r. missner
level(3) communications
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:40 AM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
t.r.
thank you very much for this information...while i suppose you're right that
it's not as good as a fix, it is much better than the brick wall that i've
been facing (my app cannot be shipped in its current state). your
workaround should be relatively easy to implement and i can't argue with
your success rate!
thanks again, and i'll let you know if i learn anything new.
chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 3:35 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is catch
the exception and try the insert again with another connection. If it still
fails I delete the connections I have and create new ones and the insert
ALWAYS works after that. So it appears to me that something is happening
to my connection object that is causing it to get corrupted to some extent.
Once a connection throws this exception it seems much more likely to do so
again which is why I am deleting connections and creating new ones if I have
2 failures back to back. This isn't the answer you are looking for but
I hoped it might help you think of other ways to troubleshoot your problem.
Since I put this work around in I have been able to run a very high rate
and haven't lost any data on the insert side. My guess is that these
Fastpath
transactions are very slow compared to non fastpath transactions and it
is easy to use a connection that hasn't finished what it is doing.
I even used a synchronized method to hopefully block on the connection
but this didn't fix the problem either. Must be some threading going on
in the connection class. I haven't had the time to go through the code
but I will at some point.
I know someone out there has some insight that could help.
t.r. missner
level(3) communications
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:40 AM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versionconten
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is catch
the exception and try the insert again with another connection. If it still
fails I delete the connections I have and create new ones and the insert
ALWAYS works after that. So it appears to me that something is happening
to my connection object that is causing it to get corrupted to some extent.
Once a connection throws this exception it seems much more likely to do so
again which is why I am deleting connections and creating new ones if I have
2 failures back to back. This isn't the answer you are looking for but
I hoped it might help you think of other ways to troubleshoot your problem.
Since I put this work around in I have been able to run a very high rate
and haven't lost any data on the insert side. My guess is that these
Fastpath
transactions are very slow compared to non fastpath transactions and it
is easy to use a connection that hasn't finished what it is doing.
I even used a synchronized method to hopefully block on the connection
but this didn't fix the problem either. Must be some threading going on
in the connection class. I haven't had the time to go through the code
but I will at some point.
I know someone out there has some insight that could help.
t.r. missner
level(3) communications
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:40 AM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, docume
[JDBC] JDBC driver in FFJ3.0
I installed FFJ3.0 on a RH7.0, jdk1.3.1 machine. I followed the instructions for installing jdbc drivers and at the test stage I got an error message: "Unable to perform action, null" However, in the Output Window (on top of which the error window came up) I have 4 lines that prove connection to the db: Testing driver org.postgresql.Driver Test getTables(): found 57 tables Test getColumns(): Table addresses contains 20 columns Test getPrimaryKeys(): Table addresses contains 1 primary keys Does anyone know where the error might have come from? (including some feature addresses table does not have). Thank you all. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
follow-up question - you say that if you get one exception, you try the
insert with another connection...if that doesn't work you delete the
existing connections and get new ones...
i must be missing something - why wouldn't using the second connection
always work? if you get rid of the offending connection (the first one),
why does the second one have a problem? or am i confusing your connection
object with the actual connection?
thanks
chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 3:35 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris,
I had the same problem on the insert side and thought it went away but
it is back and I am convinced it is related to more than one thread using
the same connection at the same time. What I have done as a work around
in the interim ( until I write my own connection manager class ) is catch
the exception and try the insert again with another connection. If it still
fails I delete the connections I have and create new ones and the insert
ALWAYS works after that. So it appears to me that something is happening
to my connection object that is causing it to get corrupted to some extent.
Once a connection throws this exception it seems much more likely to do so
again which is why I am deleting connections and creating new ones if I have
2 failures back to back. This isn't the answer you are looking for but
I hoped it might help you think of other ways to troubleshoot your problem.
Since I put this work around in I have been able to run a very high rate
and haven't lost any data on the insert side. My guess is that these
Fastpath
transactions are very slow compared to non fastpath transactions and it
is easy to use a connection that hasn't finished what it is doing.
I even used a synchronized method to hopefully block on the connection
but this didn't fix the problem either. Must be some threading going on
in the connection class. I haven't had the time to go through the code
but I will at some point.
I know someone out there has some insight that could help.
t.r. missner
level(3) communications
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 11:40 AM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult && i < iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println("SBHDocument.loadComplex exception
attempt:"+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log("SBHDocument.loadComplex attempt:"+i);
Log.log("SBHDocument.loadComplex e:"+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, version
Re: [JDBC] Read transactions don't work on 7.0.x db's 3rd attempt
-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 Connection.patch ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Patch for jdbc2 ResultSet.java
At 12:41 PM 9/5/2001, Joseph Shraibman wrote:
>new patch:
There still seems to be an error with the same if-block.
! if (index>=-rows.size())
! internalIndex=rows.size()+index;
becomes
! if (index > -rows_size)
! internalIndex = rows_size+index;
Note that the original used >=, not >.
Also, why is the first edit being done? Granted it's faster in that it
doesn't null out the array of rows, but won't that have other effects? I'm
not very familiar with the code, so pardon if I'm off base on that.
//release resources held (memory for tuples)
if(rows!=null) {
- rows.setSize(0);
rows=null;
}
Peace,
Dave
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [JDBC] [PATCHES] Patch for jdbc2 ResultSet.java
> > > Barry Lind wrote: > > Joseph, > > > > In looking at this patch it looks OK, except for the following change: > > > > > ! if (index>=-rows.size()) > > > --- 725,737 > > > ! if (index > rows_size) > > > > I haven't looked at the entire method, but the change you made seems > > incorrect. > > > Oops! Thanks for catching that. Cut and paste error. I hate those. > > > If you want this patch to be applied it should be sent to the > > pgsql-patches mail list. > > > I thought that jdbc stuff was preferred to be on the jdbc list. I guess not. Actually, yes, I throw stuff to jdbc and patches for completeness. jdbc people, tell me what you want done in the future. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] driver source code indentation
On Tue, Sep 04, 2001 at 04:59:20PM -0400, Tom Lane wrote: > Barry Lind <[EMAIL PROTECTED]> writes: > > I am OK with the style used for the C code. However I would like the > > following additional step done for the java code: replace all tabs with > > spaces. > > I disagree with this, because then we are *not* applying the same coding > standards in the backend and in JDBC. If you want to propose that we > dispense with tabs throughout the system, feel free to propose that --- > but it was shot down last time and likely will be again. > > I personally concur that four-space tabs is a horrible standard, and > would much rather see us using eight-space tab stops. But I haven't > been able to obtain any significant consensus for that view. Some > developers apparently use editors where a physical tab character needs > to equal the logical indent amount... I'm putting in my vote for keeping tabs and not using spaces. The thing I love about tabs is the ability to change the tabstop according to your needs. It's a flexibility that you don't get with spaces. Then again I do all my coding in vim. Other than that I'm all for cleaning up the source code to the one standard. Go for it! Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] JDBC Statement.executeBatch patch
Patch applied and files added. Thanks. > Attached is a patch for current CVS, consisting of a cvs diff -c > for the changed files and a few new files: > - test/jdbc2/BatchExecuteTest.java > - util/MessageTranslator.java > - jdbc2/PBatchUpdateException.java > > As an aside, is this the best way to submit a patch consisting > of both changed and new files? Or is there a smarter cvs command > which gets them all in one patch file? > > This patch fixes batch processing in the JDBC driver to be > JDBC-2 compliant. Specifically, the changes introduced by this > patch are: > > 1) Statement.executeBatch() no longer commits or rolls back a > transaction, as this is not prescribed by the JDBC spec. Its up > to the application to disable autocommit and to commit or > rollback the transaction. Where JDBC talks about "executing the > statements as a unit", it means executing the statements in one > round trip to the backend for better performance, it does not > mean executing the statements in a transaction. > > 2) Statement.executeBatch() now throws a BatchUpdateException() > as required by the JDBC spec. The significance of this is that > the receiver of the exception gets the updateCounts of the > commands that succeeded before the error occurred. In order for > the messages to be translatable, java.sql.BatchUpdateException > is extended by org.postgresql.jdbc2.PBatchUpdateException() and > the localization code is factored out from > org.postgresql.util.PSQLException to a separate singleton class > org.postgresql.util.MessageTranslator. > > 3) When there is no batch or there are 0 statements in the batch > when Statement.executeBatch() is called, do not throw an > SQLException, but silently do nothing and return an update count > array of length 0. The JDBC spec says "Throws an SQLException if > the driver does not support batch statements", which is clearly > not the case. See testExecuteEmptyBatch() in > BatchExecuteTest.java for an example. The message > postgresql.stat.batch.empty is removed from the language > specific properties files. > > 4) When Statement.executeBatch() is performed, reset the > statement's list of batch commands to empty. The JDBC spec isn't > 100% clear about this. This behaviour is only documented in the > Java tutorial > (http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html). > Note that the Oracle JDBC driver also resets the statement's > list in executeBatch(), and this seems the most reasonable > interpretation. > > 5) A new test case is added to the JDBC test suite which tests > various aspects of batch processing. See the new file > BatchExecuteTest.java. > > Regards, > Ren? Pijlman [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [JDBC] [PATCHES] Patch for broken JDBC's getColumn()
Patch applied. Thanks.
> Hi,
>
> Attached is a patch for JDBC's getColumn() function that was broken /
> flawed in the following ways:
>
> 1. Only returned columns that had a default value defined, rather than all
> columns in a table
> 2. Used 2 * N + 1 queries to find out attributes, comments and typenames
> for N columns.
>
> By using some outer join syntax it is possible to retrieve all necessary
> information in just one SQL statement. This means this version is only
> suitable for PostgreSQL >= 7.1. Don't know whether that's a problem.
>
> I've tested this function with current sources and 7.1.3 and patched both
> jdbc1 and jdbc2. I haven't compiled nor tested the jdbc1 version though, as
> I have no JDK 1.1 available.
>
> Note the discussion in http://fts.postgresql.org/db/mw/msg.html?mid=1029626
> regarding differences in obtaining comments on database object in 7.1 and
> 7.2. I was unable to use the following syntax (or similar ones):
>
> select
> ...,
> description
> from
> ...
> left outer join col_description(a.attrelid, a.attnum) description
> order by
> c.relname, a.attnum;
>
> (the error was parse error at or near '(') so I had to paste the actual
> code for the col_description function into the left outer join. Maybe
> someone who is more knowledgable about outer joins might provide me with a
> better SQL statement.
>
> Please review.
>
> Regards,
>
>
> Jeroen
[ 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] Re: Proposal to fix Statement.executeBatch()
Barry, I just applied this patch and a few others. Let me know if they
are OK.
> Rene,
>
> This writeup looks good. As for your two followup questions:
>
> 1) I agree with your opinion on the select issue. Since selects are
> the only way to call functions and functions could themselves be doing
> inserts/updates, to not allow selects is a bad idea IMHO.
>
> 2) The 8K limitation was removed from the database in 7.0 and from the
> JDBC driver in 7.0.2. Therefore I don't think we should code for the
> case of a 7.2 JDBC driver needing to support a 6.5 database.
>
> thanks,
> --Barry
>
>
> Rene Pijlman wrote:
> > On Mon, 27 Aug 2001 22:57:13 -0700, Barry Lind wrote:
> >
> >>I do not know what the server does if you have autocommit enabled
> >>and you issue multiple statements in one try.
> >>
> >
> > As you know, Peter Eisentraut said on hackers that all
> > statements in a semicolon-separated query string are processed
> > as one single transaction. So, if in "S1;S2;S3" S2 fails, both
> > S1, S2 and S3 are rolled back and in effect they have all
> > failed.
> >
> > I think this means we can implement your proposal. I've removed
> > the paragraph saying that we can't and I've added the following
> > to http://lab.applinet.nl/postgresql-jdbc/#Batch
> >
> > -+-+-
> >
> > The current implementation of Statement.executeBatch() in the
> > JDBC driver does not provide any performance improvement
> > compared to processing statements individually. This is because
> > the driver executes the statements one-by-one when
> > executeBatch() is called, using one round trip per statement. We
> > intend to reimplement executeBatch() in the following way.
> >
> > Statement.executeBatch() will send all statements in a single
> > semicolon separated query string, with only one round trip to
> > the backend. This will provide a performance improvement, as
> > intended by the JDBC specification.
> >
> > The updateCounts array will be set as described below. Note that
> > the JDBC spec defines the meaning of the following special
> > values:
> >
> > -2 the statement was executed successfully but the number of
> > affected rows is unknown
> > -3 the statement failed to execute successfully
> >
> > If all statements succeed, executeBatch() returns an
> > updateCounts array with a row count for each statement in the
> > batch, however the value for all but the last statement will be
> > -2. The value for the last statement will be a proper update
> > count.
> > If a statement fails, executeBatch() throws a
> > BatchUpdateException containing an updateCounts array with a row
> > count of -3 for each statement in the batch.
> >
> > Note that the behaviour will be the same when autocommit is
> > enabled and when it is disabled. Even with autocommit enabled,
> > the backend will commit or rollback all statements in the
> > semicolon-separated query string as a unit.
> >
> > The new implementation of executeBatch() will cause a change in
> > behaviour of the driver: the driver will no longer return update
> > counts for all statements in a batch like it currently does, it
> > will return -2 ("unknown") for most statements. However, this
> > behaviour is allowed by the JDBC spec and applications should be
> > prepared to handle it.
> >
> > -+-+-
> >
> > I see two more issues we need to decide on...
> >
> > 1) The JDBC spec requires Statement.executeBatch() to throw a
> > BatchUpdateException if any of the statements does not return an
> > update count (e.g. is a SELECT). How can we implement this? Do
> > we need to parse the statements in the JDBC driver to detect
> > SELECT's? It is a matter of interpretation, but it seems OK to
> > me to just ignore this and return -2/-3 for SELECT's as well. In
> > fact, perhaps we should allow SELECT's for function calls!?
> >
> > 2) The reimplementation may cause the driver to send very long
> > statements to the backend. I heard something about an 8K limit.
> > In what version of the backend was this limitation removed? I
> > guess we should implement the new algorithm conditionally, so
> > we'll only send multi-statement query strings to a backend that
> > has no statement length limitation.
> >
> > Regards,
> > Ren? Pijlman <[EMAIL PROTECTED]>
> >
>
>
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" 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] driver source code indentation
Well, my vote would be for a 2 space indent. Dave On Tue, 2001-09-04 at 16:59, Tom Lane wrote: > Barry Lind <[EMAIL PROTECTED]> writes: > > I am OK with the style used for the C code. However I would like the > > following additional step done for the java code: replace all tabs with > > spaces. > > I disagree with this, because then we are *not* applying the same coding > standards in the backend and in JDBC. If you want to propose that we > dispense with tabs throughout the system, feel free to propose that --- > but it was shot down last time and likely will be again. > > I personally concur that four-space tabs is a horrible standard, and > would much rather see us using eight-space tab stops. But I haven't > been able to obtain any significant consensus for that view. Some > developers apparently use editors where a physical tab character needs > to equal the logical indent amount... > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[JDBC] JDBC patch procedures (Re: [PATCHES] Patch for jdbc2 ResultSet.java)
Joseph Shraibman <[EMAIL PROTECTED]> writes: > Barry Lind wrote: >> If you want this patch to be applied it should be sent to the >> pgsql-patches mail list. > I thought that jdbc stuff was preferred to be on the jdbc list. > I guess not. Well, patches are patches, and it's easier for the committers to spot proposed patches that go by on pgsql-patches. However, the people who are competent to review JDBC patches all seem to be hanging out on the JDBC list. Seems like there are a couple of ways that we could handle this: 1. First draft of a JDBC patch goes to JDBC list; if it passes muster there then resend to pgsql-patches for application. 2. JDBC patches go to psql-patches only, and interested JDBC people subscribe to pgsql-patches so they can kibitz. 3. We give commit privileges to one or two JDBC regulars, who take responsibility for reviewing and applying JDBC-related patches after discussion on pgsql-jdbc. (This was the old setup with Peter Mount, but he seems not to have many spare cycles for Postgres anymore.) Of these #3 seems like the solution that will emerge in the long term anyway; but do we have candidate patch-meisters now? Comments, better ideas, nominations, volunteers? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Proposal to fix Statement.executeBatch()
Rene,
This writeup looks good. As for your two followup questions:
1) I agree with your opinion on the select issue. Since selects are
the only way to call functions and functions could themselves be doing
inserts/updates, to not allow selects is a bad idea IMHO.
2) The 8K limitation was removed from the database in 7.0 and from the
JDBC driver in 7.0.2. Therefore I don't think we should code for the
case of a 7.2 JDBC driver needing to support a 6.5 database.
thanks,
--Barry
Rene Pijlman wrote:
> On Mon, 27 Aug 2001 22:57:13 -0700, Barry Lind wrote:
>
>>I do not know what the server does if you have autocommit enabled
>>and you issue multiple statements in one try.
>>
>
> As you know, Peter Eisentraut said on hackers that all
> statements in a semicolon-separated query string are processed
> as one single transaction. So, if in "S1;S2;S3" S2 fails, both
> S1, S2 and S3 are rolled back and in effect they have all
> failed.
>
> I think this means we can implement your proposal. I've removed
> the paragraph saying that we can't and I've added the following
> to http://lab.applinet.nl/postgresql-jdbc/#Batch
>
> -+-+-
>
> The current implementation of Statement.executeBatch() in the
> JDBC driver does not provide any performance improvement
> compared to processing statements individually. This is because
> the driver executes the statements one-by-one when
> executeBatch() is called, using one round trip per statement. We
> intend to reimplement executeBatch() in the following way.
>
> Statement.executeBatch() will send all statements in a single
> semicolon separated query string, with only one round trip to
> the backend. This will provide a performance improvement, as
> intended by the JDBC specification.
>
> The updateCounts array will be set as described below. Note that
> the JDBC spec defines the meaning of the following special
> values:
>
> -2 the statement was executed successfully but the number of
> affected rows is unknown
> -3 the statement failed to execute successfully
>
> If all statements succeed, executeBatch() returns an
> updateCounts array with a row count for each statement in the
> batch, however the value for all but the last statement will be
> -2. The value for the last statement will be a proper update
> count.
> If a statement fails, executeBatch() throws a
> BatchUpdateException containing an updateCounts array with a row
> count of -3 for each statement in the batch.
>
> Note that the behaviour will be the same when autocommit is
> enabled and when it is disabled. Even with autocommit enabled,
> the backend will commit or rollback all statements in the
> semicolon-separated query string as a unit.
>
> The new implementation of executeBatch() will cause a change in
> behaviour of the driver: the driver will no longer return update
> counts for all statements in a batch like it currently does, it
> will return -2 ("unknown") for most statements. However, this
> behaviour is allowed by the JDBC spec and applications should be
> prepared to handle it.
>
> -+-+-
>
> I see two more issues we need to decide on...
>
> 1) The JDBC spec requires Statement.executeBatch() to throw a
> BatchUpdateException if any of the statements does not return an
> update count (e.g. is a SELECT). How can we implement this? Do
> we need to parse the statements in the JDBC driver to detect
> SELECT's? It is a matter of interpretation, but it seems OK to
> me to just ignore this and return -2/-3 for SELECT's as well. In
> fact, perhaps we should allow SELECT's for function calls!?
>
> 2) The reimplementation may cause the driver to send very long
> statements to the backend. I heard something about an 8K limit.
> In what version of the backend was this limitation removed? I
> guess we should implement the new algorithm conditionally, so
> we'll only send multi-statement query strings to a backend that
> has no statement length limitation.
>
> Regards,
> René Pijlman <[EMAIL PROTECTED]>
>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [JDBC] Patch for jdbc2 ResultSet.java
Barry Lind wrote:
> Joseph,
>
> In looking at this patch it looks OK, except for the following change:
>
> > ! if (index>=-rows.size())
> > --- 725,737
> > ! if (index > rows_size)
>
> I haven't looked at the entire method, but the change you made seems
> incorrect.
>
Oops! Thanks for catching that. Cut and paste error. I hate those.
> If you want this patch to be applied it should be sent to the
> pgsql-patches mail list.
I thought that jdbc stuff was preferred to be on the jdbc list. I guess not.
new patch:
*** ResultSet.java.orig Tue Sep 4 16:34:14 2001
--- ResultSet.java Wed Sep 5 15:35:59 2001
***
*** 134,140
{
//release resources held (memory for tuples)
if(rows!=null) {
- rows.setSize(0);
rows=null;
}
}
--- 134,139
***
*** 709,716
public int findColumn(String columnName) throws SQLException
{
int i;
!
! for (i = 0 ; i < fields.length; ++i)
if (fields[i].getName().equalsIgnoreCase(columnName))
return (i+1);
throw new PSQLException ("postgresql.res.colname",columnName);
--- 708,715
public int findColumn(String columnName) throws SQLException
{
int i;
! final int flen = fields.length;
! for (i = 0 ; i < flen; ++i)
if (fields[i].getName().equalsIgnoreCase(columnName))
return (i+1);
throw new PSQLException ("postgresql.res.colname",columnName);
***
*** 726,736
if (index==0)
throw new SQLException("Cannot move to index of 0");
//if index<0, count from the end of the result set, but check
//to be sure that it is not beyond the first index
if (index<0)
! if (index>=-rows.size())
! internalIndex=rows.size()+index;
else {
beforeFirst();
return false;
--- 725,737
if (index==0)
throw new SQLException("Cannot move to index of 0");
+ final int rows_size = rows.size();
+
//if index<0, count from the end of the result set, but check
//to be sure that it is not beyond the first index
if (index<0)
! if (index > -rows_size)
! internalIndex = rows_size+index;
else {
beforeFirst();
return false;
***
*** 739,745
//must be the case that index>0,
//find the correct place, assuming that
//the index is not too large
! if (index<=rows.size())
internalIndex = index-1;
else {
afterLast();
--- 740,746
//must be the case that index>0,
//find the correct place, assuming that
//the index is not too large
! if (index <= rows_size)
internalIndex = index-1;
else {
afterLast();
***
*** 753,760
public void afterLast() throws SQLException
{
! if (rows.size() > 0)
! current_row = rows.size();
}
public void beforeFirst() throws SQLException
--- 754,762
public void afterLast() throws SQLException
{
! final int rows_size = rows.size();
! if (rows_size > 0)
! current_row = rows_size;
}
public void beforeFirst() throws SQLException
***
*** 967,973
public boolean isAfterLast() throws SQLException
{
! return (current_row >= rows.size() && rows.size() > 0);
}
public boolean isBeforeFirst() throws SQLException
--- 969,976
public boolean isAfterLast() throws SQLException
{
! final int rows_size = rows.size();
! return (current_row >= rows_size && rows_size > 0);
}
public boolean isBeforeFirst() throws SQLException
***
*** 982,995
public boolean isLast() throws SQLException
{
! return (current_row == rows.size() -1 && rows.size() > 0);
}
public boolean last() throws SQLException
{
! if (rows.size() <= 0)
return false;
! current_row = rows.size() - 1;
this_row = (byte [][])rows.elementAt(current_row);
return true;
}
--- 985,1000
public boolean isLast() throws SQLException
{
! final int rows_size = rows.size();
! return (current_row == rows_size -1 && rows_size > 0);
}
public boolean last() throws SQLException
{
! final int rows_size = rows.size();
! if (rows_size <= 0)
return false;
! current_row = rows_size - 1;
this_row = (byte [][])rows.elementAt(current_row);
return true;
}
***
*** 1480,1483
}
}
}
-
--- 1485,1487
--
Joseph Shraibman
[EMAIL PROTECTED]
Increase signal to noise ratio. http://www.targabot.com
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] Attempt to clean up ExecSql() in JDBC
Patch applied and file added. Thanks. > > Hi, > > Attached is my attempt to clean up the horrors of the ExecSQL() method in > the JDBC driver. > > I've done this by extracting it into a new method object called > QueryExecutor (should go into org/postgresql/core/) and then taking it > apart into different methods in that class. > > A short summary: > > * Extracted ExecSQL() from Connection into a method object called > QueryExecutor. > > * Moved ReceiveFields() from Connection to QueryExecutor. > > * Extracted parts of the original ExecSQL() method body into smaller > methods on QueryExecutor. > > * Bug fix: The instance variable "pid" in Connection was used in two > places with different meaning. Both were probably in dead code, but it's > fixed anyway. > > /Anders > > > PS.: If anyone has any idea what the variable names "fqp" and "hfr" stand > for, please tell me! :) > > _ > A n d e r s B e n g t s s o n [EMAIL PROTECTED] > Stockholm, Sweden Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
