Nabble - PostgreSQL - jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T06:03:43Z

Oliver Jowett, 25.11.2009 14:42:
> You never call getMoreResults(), so you are only looking at a single
> result, which is either a resultset or an update count, never both.
[...]
Hmm, sorry I missed that in my initial email then. I did call getMoreResults()

The following still returns false for getMoreResults()

PreparedStatement pstmt = con.prepareStatement(update);
pstmt.setInt(1, 1);
boolean hasResult = pstmt.execute();

if (hasResult ) {
ResultSet rs = pstmt.getResultSet();
if (rs != null && rs.next()) {
int newId = rs.getInt(1);
System.out.println("newid: " + newId);
}
}
boolean more = pstmt.getMoreResults(); // returns false

> You may have more success using something like this:
>
>> PreparedStatement pstmt = con.prepareStatement("UPDATE something with no RETURNING clause", new String[] { "some_column" });
>> int updateCount = pstmt.executeUpdate();
>> ResultSet results = pstmt.getGeneratedKeys();

That indeed works!

But I still think the behaviour with getMoreResults() is - at least - confusing ;)

Thanks a lot for all your patience!

Thomas

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T05:42:27Z

Oliver Jowett wrote:

> You never call getMoreResults(), so you are only looking at a single
> result, which is either a resultset or an update count, never both.

Also, looking at the code a bit more, RETURNING is a bit of a special
case. Normally, if you have a command that returns a resultset, the
command status is ignored (you generally don't care about the command
status of, for example, a SELECT). Presumably that's happening here too.
(But the advice regarding getMoreResults() is generally applicable, e.g.
if you have a multiple-statement query).

You may have more success using something like this:

> PreparedStatement pstmt = con.prepareStatement("UPDATE something with no RETURNING clause", new String[] { "some_column" });
> int updateCount = pstmt.executeUpdate();
> ResultSet results = pstmt.getGeneratedKeys();

The driver glues on an appropriate RETURNING clause and arranges for the
resulting resultset to appear via getGeneratedKeys(); the update count
should still appear as expected.

(I haven't actually tried this. caveat emptor)

-O

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T05:14:24Z

Thomas Kellerer wrote:

> Back to my original question then: why doesn't the Postgres driver
> return 1 as the updateCount in this situation?
> I only get a single result set (which is correct) but never a 1 as the
> update count.

Back to my original answer then ;-)

Quoting your original code:

> PreparedStatement pstmt = con.prepareStatement(UPDATE_SQL); // the statement from above
> pstmt.setInt(1, 42);
> boolean hasResult = pstmt.execute();
>
> if (hasResult) {
> ResultSet rs = pstmt.getResultSet();
> if (rs != null && rs.next()) {
> int newId = rs.getInt(1);
> System.out.println("newid: " + newId);
> }
> }
>
> int affected = pstmt.getUpdateCount();
> System.out.println("affected: " + affected);

You never call getMoreResults(), so you are only looking at a single
result, which is either a resultset or an update count, never both.

-O

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T04:30:17Z

Oliver Jowett, 25.11.2009 13:16:

>> So if I create a loop using the condition stated in the Javadocs the
>> program flow would be as follows:
>>
>> 1) stmt.execute() returns true, so I call getResultSet()
>> 2) getMoreResults() returns false, but getUpdateCount() returns 3 ==> go on
>> 3) getMoreResults() returns false, but getUpdateCount() returns 2 ==> go on
>> 4) getMoreResults() returns true, so getResultSet() returns a result set
>> ==> go on
>> 5) getMoreResults() returns true, so getResultSet() returns a result set
>> ==> go on
>> 6) getMoreResults() returns false, getUpdateCount() returns -1 ==>
>> everything was processed.
>
> Yes, this is correct. It will look something like this:

So my understanding was correct ;)

Back to my original question then: why doesn't the Postgres driver return 1 as the updateCount in this situation?

I only get a single result set (which is correct) but never a 1 as the update count.

Regards
Thomas

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T04:16:20Z

Thomas Kellerer wrote:

> Oliver Jowett, 25.11.2009 12:13:
>>
>> You've done some selective editing there. The javadoc I referred to is
>> this (from the Java 6 javadoc):
>>
>> getResultSet():
>>
>> Retrieves the current result as a ResultSet object. This method should
>> be called only once per result.
>
> Correct, once per *result* not per statement. If the statement returns
> more than one result, I should be allowed to call it multiple time.

That's right, but you need a call to getMoreResults() to step through
the results between calls, as I suggested in my original response.

> I think the base of my (mis)understanding is that the term "current"
> lead me to believe that the "stack" of results a statement can hold,
> could look like this:
>
> resultSet
> update count = 3
> update count = 2
> resultSet
> reslutSet

Yes, you can have that. You step through the results by calling
getMoreResults(). At any particular point, the current result is either
a resultset or an update count, but never both.

> So if I create a loop using the condition stated in the Javadocs the
> program flow would be as follows:
>
> 1) stmt.execute() returns true, so I call getResultSet()
> 2) getMoreResults() returns false, but getUpdateCount() returns 3 ==> go on
> 3) getMoreResults() returns false, but getUpdateCount() returns 2 ==> go on
> 4) getMoreResults() returns true, so getResultSet() returns a result set
> ==> go on
> 5) getMoreResults() returns true, so getResultSet() returns a result set
> ==> go on
> 6) getMoreResults() returns false, getUpdateCount() returns -1 ==>
> everything was processed.

Yes, this is correct. It will look something like this:

boolean hasResultSet = stmt.execute();
int updateCount = stmt.getUpdateCount();
while (hasResultSet || updateCount != -1) {
if (hasResultSet) {
ResultSet rs = stmt.getResultSet();
// This result is a resultset, process rs.
} else {
// This result is an update count, process updateCount.
}

hasResultSet = stmt.getMoreResults();
updateCount = stmt.getUpdateCount();
}

-O

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T03:53:17Z

Oliver Jowett, 25.11.2009 12:13:
>
> You've done some selective editing there. The javadoc I referred to is
> this (from the Java 6 javadoc):
>
> getResultSet():
>
> Retrieves the current result as a ResultSet object. This method should
> be called only once per result.

Correct, once per *result* not per statement. If the statement returns more than one result, I should be allowed to call it multiple time.

I think the base of my (mis)understanding is that the term "current" lead me to believe that the "stack" of results a statement can hold, could look like this:

resultSet
update count = 3
update count = 2
resultSet
reslutSet

So if I create a loop using the condition stated in the Javadocs the program flow would be as follows:

1) stmt.execute() returns true, so I call getResultSet()
2) getMoreResults() returns false, but getUpdateCount() returns 3 ==> go on
3) getMoreResults() returns false, but getUpdateCount() returns 2 ==> go on
4) getMoreResults() returns true, so getResultSet() returns a result set ==> go on
5) getMoreResults() returns true, so getResultSet() returns a result set ==> go on
6) getMoreResults() returns false, getUpdateCount() returns -1 ==> everything was processed.

Apparently this interpretation of "current", "next" and "once per _result_" was wrong...

Regards
Thomas

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-25T03:13:40Z

Thomas Kellerer wrote:

> Hmm, my understand was a bit different.
> The Javadocs simply say
>
> There are no more results when the following is true:
> ((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))
>
> It doesn't state that they are mutually exclusive. And for me it seemed
> to imply that I can call getMoreResults() and getUpdateCount() in a loop
> in order to process everything that is returned.
>
> Additionally the Javadocs for getUpdateCount() says:
>
> "Gets the *current* result as an update count" and ".. if there are no
> more results it returns -1"

You've done some selective editing there. The javadoc I referred to is
this (from the Java 6 javadoc):

getResultSet():

Retrieves the current result as a ResultSet object. This method should
be called only once per result.

Returns: the current result as a ResultSet object or null if the result
is an update count or there are no more results

---

getUpdateCount():

Retrieves the current result as an update count; if the result is a
ResultSet object or there are no more results, -1 is returned. This
method should be called only once per result.

Returns: the current result as an update count; -1 if the current result
is a ResultSet object or there are no more results

---

I think that's fairly clear: the "current result" is either a ResultSet,
or an update count, but it can't be both. getUpdateCount() explicitly
says that it returns "-1 [...] if the current result is a ResultSet
object", and getResultSet() explicitly says that it returns "null if the
[current] result is an update count."

> The word "current" here also let me to believe I can call those methods
> multiple times.

From memory the postgresql driver doesn't care if you call them
multiple times, but FWIW the javadoc says that you should only call them
once per result.

-O

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-24T23:31:37Z

Oliver Jowett, 25.11.2009 01:40:

> Thomas Kellerer wrote:
>
>> boolean hasResult = pstmt.execute();
>>
>> if (hasResult) {
>> ResultSet rs = pstmt.getResultSet();
>> if (rs != null && rs.next()) {
>> int newId = rs.getInt(1);
>> System.out.println("newid: " + newId);
>> }
>> }
>>
>> int affected = pstmt.getUpdateCount();
>> System.out.println("affected: " + affected);
>>
>> I do see the returned ID from the ResultSet but getUpdateCount() always
>> returns -1 even though I know that a row was updated.
>> What am I missing here?
>
> Update counts and result sets (for a particular result) are mutually
> exclusive. If getResultSet() returns non-null then getUpdateCount() must
> return -1; see the javadoc for those two methods.

Hmm, my understand was a bit different.

The Javadocs simply say

There are no more results when the following is true:
((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))

It doesn't state that they are mutually exclusive. And for me it seemed to imply that I can call getMoreResults() and getUpdateCount() in a loop in order to process everything that is returned.

Additionally the Javadocs for getUpdateCount() says:

"Gets the *current* result as an update count" and ".. if there are no more results it returns -1"

The word "current" here also let me to believe I can call those methods multiple times.

Regards
Thomas

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: getUdateCount() vs. RETURNING clause

2009-11-24T16:40:30Z

Thomas Kellerer wrote:

> boolean hasResult = pstmt.execute();
>
> if (hasResult) {
> ResultSet rs = pstmt.getResultSet();
> if (rs != null && rs.next()) {
> int newId = rs.getInt(1);
> System.out.println("newid: " + newId);
> }
> }
>
> int affected = pstmt.getUpdateCount();
> System.out.println("affected: " + affected);
>
> I do see the returned ID from the ResultSet but getUpdateCount() always
> returns -1 even though I know that a row was updated.
> What am I missing here?

Update counts and result sets (for a particular result) are mutually
exclusive. If getResultSet() returns non-null then getUpdateCount() must
return -1; see the javadoc for those two methods.

You probably want to call getMoreResults() in there somewhere to step to
the next result.

-O

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

getUdateCount() vs. RETURNING clause

2009-11-24T03:45:26Z

Hi,

I'm having a problem using an UPDATE statement with a RETURNING clause.

It seems I cannot retrieve the number of rows affected using getUpdateCount()

This is my statement

UPDATE my_table
SET the_column = the_column + 1
WHERE id = =
RETURNING the_column;

My Java code is:

PreparedStatement pstmt = con.prepareStatement(UPDATE_SQL); // the statement from above
pstmt.setInt(1, 42);
boolean hasResult = pstmt.execute();

if (hasResult) {
ResultSet rs = pstmt.getResultSet();
if (rs != null && rs.next()) {
int newId = rs.getInt(1);
System.out.println("newid: " + newId);
}
}

int affected = pstmt.getUpdateCount();
System.out.println("affected: " + affected);

I do see the returned ID from the ResultSet but getUpdateCount() always returns -1 even though I know that a row was updated.

What am I missing here?

My Postgres version is: 8.4.1
My driver version is: PostgreSQL 8.4 JDBC4 (build 701)
I'm using Java6 (1.6.0_16)

Regards
Thomas

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: COPY and turning off autocommit

2009-11-20T15:45:57Z

On Thu, 19 Nov 2009, Maciek Sakrejda wrote:

> The attached fixes the issue by adapting the internal API to mimic the
> Fastpath subprotocol with respect to transactions. It does not include
> the test patch above.
>
> Any thoughts?

This looks like the right approach at a quick glance. I'm going on
vacation next week, but when I return I will review and commit.

Kris Jurka

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: COPY and turning off autocommit

2009-11-19T13:25:13Z

The attached fixes the issue by adapting the internal API to mimic the
Fastpath subprotocol with respect to transactions. It does not include
the test patch above.

The full suite (with the added test) passes with postgresql 8.3 under
both Java 5 and 6. I don't have 1.4 handy, but I did make the
necessary (trivial) change to the v2 QueryExecutorImpl.

Any thoughts?

--
Maciek Sakrejda | Software Engineer | Truviso

1065 E. Hillsdale Blvd., Suite 230
Foster City, CA 94404
(650) 242-3500 Main
(650) 242-3501 F
www.truviso.com

[copy-tx-fix.patch]

Index: org/postgresql/core/QueryExecutor.java =================================================================== RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/QueryExecutor.java,v retrieving revision 1.44 diff -r1.44 QueryExecutor.java 223c223 < CopyOperation startCopy(String sql) throws SQLException; --- > CopyOperation startCopy(String sql, boolean suppressBegin) throws SQLException; Index: org/postgresql/core/v2/QueryExecutorImpl.java =================================================================== RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/v2/QueryExecutorImpl.java,v retrieving revision 1.22 diff -r1.22 QueryExecutorImpl.java 610c610 < public CopyOperation startCopy(String sql) throws SQLException { --- > public CopyOperation startCopy(String sql, boolean suppressBegin) throws SQLException { Index: org/postgresql/core/v3/QueryExecutorImpl.java =================================================================== RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/core/v3/QueryExecutorImpl.java,v retrieving revision 1.45 diff -r1.45 QueryExecutorImpl.java 475c475,492 < if (protoConnection.getTransactionState() == ProtocolConnection.TRANSACTION_IDLE && !suppressBegin) --- > if (!suppressBegin) > { > doSubprotocolBegin(); > } > try > { > sendFastpathCall(fnid, (SimpleParameterList)parameters); > return receiveFastpathResult(); > } > catch (IOException ioe) > { > protoConnection.close(); > throw new PSQLException(GT.tr("An I/O error occured while sending to the backend."), PSQLState.CONNECTION_FAILURE, ioe); > } > } > > public void doSubprotocolBegin() throws SQLException { > if (protoConnection.getTransactionState() == ProtocolConnection.TRANSACTION_IDLE) 479c496 < logger.debug("Issuing BEGIN before fastpath call."); --- > logger.debug("Issuing BEGIN before fastpath or copy call."); 540,549d556 < try < { < sendFastpathCall(fnid, (SimpleParameterList)parameters); < return receiveFastpathResult(); < } < catch (IOException ioe) < { < protoConnection.close(); < throw new PSQLException(GT.tr("An I/O error occured while sending to the backend."), PSQLState.CONNECTION_FAILURE, ioe); < } 702c709 < public synchronized CopyOperation startCopy(String sql) throws SQLException { --- > public synchronized CopyOperation startCopy(String sql, boolean suppressBegin) throws SQLException { 703a711,713 > if (!suppressBegin) { > doSubprotocolBegin(); > } Index: org/postgresql/copy/CopyManager.java =================================================================== RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/copy/CopyManager.java,v retrieving revision 1.1 diff -r1.1 CopyManager.java 42a43 > private final BaseConnection connection; 46a48 > this.connection = connection; 52c54 < op = queryExecutor.startCopy(sql); --- > op = queryExecutor.startCopy(sql, connection.getAutoCommit()); 63c65 < op = queryExecutor.startCopy(sql); --- > op = queryExecutor.startCopy(sql, connection.getAutoCommit());

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: COPY and turning off autocommit

2009-11-19T12:50:16Z

This time with attachment.

--
Maciek Sakrejda | Software Engineer | Truviso

1065 E. Hillsdale Blvd., Suite 230
Foster City, CA 94404
(650) 242-3500 Main
(650) 242-3501 F
www.truviso.com

[copy-tx-test.patch]

Index: org/postgresql/test/jdbc2/CopyTest.java =================================================================== RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/test/jdbc2/CopyTest.java,v retrieving revision 1.2 diff -r1.2 CopyTest.java 259a260,266 > public void testCopyRollback() throws SQLException { > con.setAutoCommit(false); > testCopyInByRow(); > con.rollback(); > assertEquals(0, getCount()); > } >

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: COPY and turning off autocommit

2009-11-19T12:46:08Z

Attaching a patch to add a failing test case that illustrates the
problem against CVS HEAD.

I'll try mucking about with the possible answers to my above questions
and see if I can get the suite to pass, but I'd appreciate feedback
from anyone more familiar with the protocol.

Thanks,
--
Maciek Sakrejda | Software Engineer | Truviso

1065 E. Hillsdale Blvd., Suite 230
Foster City, CA 94404
(650) 242-3500 Main
(650) 242-3501 F
www.truviso.com

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: commit and rollback don't throw exceptions when they should

2009-11-19T09:01:18Z

Kris Jurka <books@...> wrote:

> Thanks for following up on this.

Thank you for taking it all the way to what it should have been in the
first place. I've got to try to overcome this tendency to submit the
minimum patch that will directly address a complaint. I should be
willing to dive in and deal with the entire set of related issues, as
you do.

-Kevin

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: commit and rollback don't throw exceptions when they should

2009-11-18T16:59:57Z

On Wed, 18 Nov 2009, Kevin Grittner wrote:

> That all makes sense. I think you have a copy/paste error in the
> exception message, though: "This statement has been closed." It is
> the connection which has been closed here.

Doh! Fixed.

> Also, for software which tries to make sense of the SQLSTATE for
> automated handling, I'm inclined to think that something in Class Code
> '08' (Connection Exception) would be more useful than the Class Code
> '55' (Object Not in Prerequisite State) value. Granted, it's a gray
> area, since the problem with the connection is that it's not in an
> open state....

I've changed it to 08003 CONNECTION_DOES_NOT_EXIST. We're already using
it for this purpose (already closed) in the connection pooling code.

Thanks for following up on this.

Kris Jurka

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: commit and rollback don't throw exceptions when they should

2009-11-18T11:31:32Z

Kris Jurka <books@...> wrote:

> I've commited a modified version of this patch to HEAD only,
> because changing this behavior could break peoples applications.
>
> I extended the check for the connection already being closed to the
> other connection methods. There's no reason commit/rollback are
> special here.

That all makes sense. I think you have a copy/paste error in the
exception message, though: "This statement has been closed." It is
the connection which has been closed here.

Also, for software which tries to make sense of the SQLSTATE for
automated handling, I'm inclined to think that something in Class Code
'08' (Connection Exception) would be more useful than the Class Code
'55' (Object Not in Prerequisite State) value. Granted, it's a gray
area, since the problem with the connection is that it's not in an
open state....

-Kevin

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [BUGS] BUG #5177: Concurrency problem in AbstractJdbc23PooledConnection

2009-11-18T06:29:50Z

On Tue, 10 Nov 2009, Mauro Molinari wrote:

> Bug reference: 5177
> PostgreSQL version: 8.3.8
> Description: Concurrency problem in AbstractJdbc23PooledConnection
> Details:
>
> Hello, we're using PostgreSQL JDBC3 driver 8.3-605 to connect to a 8.3.8
> Postgres instance. Our application has a JTA-XA transaction infrastructure
> managed by Spring and using JBoss Transactions as a JTA implementation.
> We're using a connection pool of our own to pool XA connections on top of
> which there's JBoss Transactions transactional driver that is managing
> connections. Our connection pool infrastructure creates a PGXADataSource
> from which it gets new XA connections.
>
> In this scenario, sometimes happens that the PostgreSQL driver fails with
> the following exception:
>
> java.lang.NullPointerException
> at
> org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$ConnectionHandler.in
> voke(AbstractJdbc23PooledConnection.java:319)
> at $Proxy5.close(Unknown Source)
> at
> com.arjuna.ats.internal.jdbc.ConnectionImple.close(ConnectionImple.java:369)
>
> Looking at the JDBC driver source code, it seems a concurrency problem,
> because at row 304-305 the variable con is checked against null.
>
> What is actually happening here is that our code is closing a connection
> used to read some data from the DB. This read operation is executed outside
> any transaction, so JBoss Transactions is honouring the connection close
> request by first calling calling close on the XA connection (and this is
> causing the XA connection to be given back to our pool); after that, because
> of the actual JDBC connection reports false on isClosed(), JBoss
> Transactions is also calling close() on it too... and this generates the
> NullPointerException given above.
>
> Looking at the AbstractJdbc23PooledConnection it seems there's no
> synchronization at all between isClosed() and close(). My suspect is that in
> the previous scenario something like this happens:
> 1. thread 1: close() is invoked
> 2. thread 2: isClosed() returns false
> 3. thread 2: close() is invoked
>
> At operation 2., isClose returns false, while it should return true because
> a close request has already been made on thread 1. Anyway, there should be
> no problem at all to call close repeatedly on the same connection (as the
> JDBC contract states), so the NullPointerException should not happen in any
> case.
>

Attached is a test case which reproduces this problem easily.

> Thanks in advance and please let me know how I can monitor this bug report
> (is there any bug tracking system for PostgreSQL?).
>

There is no bug tracker for postgresql in general. The JDBC driver does
have a bug tracker, but the mailing list is where most of the action
happens.

http://pgfoundry.org/tracker/?group_id=1000224

Kris Jurka
import java.sql.*;
import javax.sql.XAConnection;

import org.postgresql.xa.PGXADataSource;

public class XaCloseTest {

public static void main(String args[]) throws Exception {
PGXADataSource ds = new PGXADataSource();
ds.setServerName("localhost");
ds.setUser("kjurka");
ds.setPassword("");
ds.setDatabaseName("kjurka");
ds.setPortNumber(5850);

XAConnection xaconn = ds.getXAConnection();

Handle h = new Handle();
h.conn = xaconn.getConnection();

for (int i=0; i<5; i++) {
Closer c = new Closer(h);
c.start();
}

Opener o = new Opener(xaconn, h);
o.start();
}

private static class Handle {
public Connection conn;
}

private static class Closer extends Thread {
private final Handle _h;

public Closer(Handle h) {
_h = h;
}

public void run() {
while (true) {
try {
_h.conn.close();
} catch (SQLException sqle) {
sqle.printStackTrace();
}
}
}
}

private static class Opener extends Thread {
private final XAConnection _xaconn;
private final Handle _h;

public Opener(XAConnection xaconn, Handle h) {
_xaconn = xaconn;
_h = h;
}

public void run() {
while (true) {
try {
_h.conn = _xaconn.getConnection();
} catch (SQLException sqle) {
sqle.printStackTrace();
}
}
}

}

}

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: commit and rollback don't throw exceptions when they should

2009-11-18T03:21:38Z

On Wed, 4 Nov 2009, Kevin Grittner wrote:

> Having received no feedback on the preliminary patch I previously
> posted, I'll suggest this (fairly minimal) patch. I didn't attempt to
> deal with the distributed transaction issue, since it seemed pretty
> messy and I wasn't sure the fix was worth the mess it would make. As
> far as I can see, it should fix the OP's problem, although it would be
> nice to get a confirmation of that.
>

I've commited a modified version of this patch to HEAD only, because
changing this behavior could break peoples applications.

I extended the check for the connection already being closed to the other
connection methods. There's no reason commit/rollback are special here.
I also needed to fix a regression testcase which was violating this rule.

Kris Jurka

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

COPY and turning off autocommit

2009-11-17T09:40:34Z

I've found that since COPY does not use the sendQueryPreamble method
in QueryExecutorImpl, it fails to issue the necessary BEGIN if it's
the first statement after autocommit is set to off.

A workaround is to just issue a "SELECT 1" before the COPY, but this
is pretty ugly.

I'm not quite sure what the proper fix is: does COPY need to go
through the full sendQueryPreamble code path (specifically,
processDeadParsedQueries() and processDeadPortals())? Also, that code
is tied into the ResultHandler interface, and COPY does not really fit
well into that paradigm. I don't think we can we just call
sendQueryPreamble(), sendSync(), processResults(), and *then* move to
COPY code, since sendQueryPreamble() might do nothing if we're already
in a transaction. I suppose we could pass in a null ResultHandler and
see if the handler returned is null (in which case there is no BEGIN
to process), but that seems egregiously ugly.

Any thoughts?

--
Maciek Sakrejda | Software Engineer | Truviso

1065 E. Hillsdale Blvd., Suite 230
Foster City, CA 94404
(650) 242-3500 Main
(650) 242-3501 F
www.truviso.com

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: Implementation of query timeout

2009-11-12T13:21:11Z

Hi,

Under http://rsmogura.net/pgsql/pgsql_jdbc_querytimeout_v2_20091112.tar.bz2
you can find newer version of statement timeout, witch is bettered propsal of
solution, but still only from non-batch statements.

Kind regards,
Radek Smogura

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: Read Timeout

2009-11-11T08:11:40Z

Michael Mangeng wrote:
> My question is weather there is a possibility to define a read timeout
> interval somewhere to avoid this. (e.g. In the JDBC url. Somthing like
> loginTimout?)

Try "socketTimeout" parameter, if you can use the current version
(8.4 Build 701) of the driver.

http://jdbc.postgresql.org/documentation/84/connect.html#connection-parameters

Regards,
Sadanori

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Read Timeout

2009-11-11T05:48:55Z

Hello all!

I've got an issue with the call to preparedStatement.executeBatch. The
performing thread is locked in a productive system for some hours in
SocketInputStream.read, as you can see in the stacktrace below. The
database server is currently reachable but it's possible that it had
been off for a few seconds (we're logging over the internet connection
to another building).

My question is weather there is a possibility to define a read timeout
interval somewhere to avoid this. (e.g. In the JDBC url. Somthing like
loginTimout?)

Stacktrace is below.

Thanks a lot and greetings,
Michael

java.net.SocketInputStream.socketRead0(null:-2)
java.net.SocketInputStream.read(null:-1)
org.postgresql.core.VisibleBufferedInputStream.readMore
(VisibleBufferedInputStream.java:135)
org.postgresql.core.VisibleBufferedInputStream.ensureBytes
(VisibleBufferedInputStream.java:104)
org.postgresql.core.VisibleBufferedInputStream.read
(VisibleBufferedInputStream.java:73)
org.postgresql.core.PGStream.ReceiveChar(PGStream.java:259)
org.postgresql.core.v3.QueryExecutorImpl.processResults
(QueryExecutorImpl.java:1166)
org.postgresql.core.v3.QueryExecutorImpl.execute
(QueryExecutorImpl.java:351)
org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch
(AbstractJdbc2Statement.java:2674)
org.apache.commons.dbcp.DelegatingStatement.executeBatch
(DelegatingStatement.java:297)

com.v8tech.pneuma.eventlogger.internal.NodeprocessingDataEntriesoggerImpl.commitBatch
(NodeEventLoggerImpl.java:462)

com.v8tech.pneuma.eventlogger.internal.NodeEventLoggerImpl.processDataEntries
(NodeEventLoggerImpl.java:378)
com.v8tech.pneuma.eventlogger.internal.NodeEventLoggerImpl.tick
(NodeEventLoggerImpl.java:502)
com.v8tech.components.ticker.Ticker$TickerRunnable$1.run(Ticker.java:
206)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(null:-1)
java.util.concurrent.ThreadPoolExecutor$Worker.run(null:-1)
java.lang.Thread.run(null:-1)

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Database connection error, try to reset the connection parameters

2009-11-05T07:50:03Z

Hi all,
im newbie in here
when im login to some application that connection to postgres
this message show
"Database connection error, try to reset the connection parameters"
any one can help me?
thanks regards
cholid.r

Re: commit and rollback don't throw exceptions when they should

2009-11-04T14:40:17Z

taktos <taktos@...> wrote:

> Drivers other than PosrgreSQL throws exception as I had expected,
> but PostgreSQL didn't throw exception.

Having received no feedback on the preliminary patch I previously
posted, I'll suggest this (fairly minimal) patch. I didn't attempt to
deal with the distributed transaction issue, since it seemed pretty
messy and I wasn't sure the fix was worth the mess it would make. As
far as I can see, it should fix the OP's problem, although it would be
nice to get a confirmation of that.

This patch is basically the same as the previous one, except that I've
updated the javadocs to match the new behavior.

If there are any issues with this, I can have another go at it.

-Kevin

Index: org/postgresql/jdbc2/AbstractJdbc2Connection.java
===================================================================
RCS file: /cvsroot/jdbc/pgjdbc/org/postgresql/jdbc2/AbstractJdbc2Connection.java,v
retrieving revision 1.52
diff -c -r1.52 AbstractJdbc2Connection.java
*** org/postgresql/jdbc2/AbstractJdbc2Connection.java 1 Jul 2009 05:00:40 -0000 1.52
--- org/postgresql/jdbc2/AbstractJdbc2Connection.java 4 Nov 2009 22:28:59 -0000
***************
*** 676,691 ****
* The method commit() makes all changes made since the previous
* commit/rollback permanent and releases any database locks currently
* held by the Connection. This method should only be used when
! * auto-commit has been disabled. (If autoCommit == true, then we
! * just return anyhow)
*
! * @exception SQLException if a database access error occurs
* @see setAutoCommit
*/
public void commit() throws SQLException
{
if (autoCommit)
! return ;

if (protoConnection.getTransactionState() != ProtocolConnection.TRANSACTION_IDLE)
executeTransactionCommand(commitQuery);
--- 676,697 ----
* The method commit() makes all changes made since the previous
* commit/rollback permanent and releases any database locks currently
* held by the Connection. This method should only be used when
! * auto-commit has been disabled.
*
! * @exception SQLException if a database access error occurs,
! * this method is called on a closed connection or
! * this Connection object is in auto-commit mode
* @see setAutoCommit
*/
public void commit() throws SQLException
{
+ if (isClosed())
+ throw new PSQLException(GT.tr("Cannot commit when connection is closed."),
+ PSQLState.CONNECTION_FAILURE);
+
if (autoCommit)
! throw new PSQLException(GT.tr("Cannot commit when autoCommit is enabled."),
! PSQLState.NO_ACTIVE_SQL_TRANSACTION);

if (protoConnection.getTransactionState() != ProtocolConnection.TRANSACTION_IDLE)
executeTransactionCommand(commitQuery);
***************
*** 696,708 ****
* commit/rollback and releases any database locks currently held by
* the Connection.
*
! * @exception SQLException if a database access error occurs
* @see commit
*/
public void rollback() throws SQLException
{
if (autoCommit)
! return ;

if (protoConnection.getTransactionState() != ProtocolConnection.TRANSACTION_IDLE)
executeTransactionCommand(rollbackQuery);
--- 702,721 ----
* commit/rollback and releases any database locks currently held by
* the Connection.
*
! * @exception SQLException if a database access error occurs,
! * this method is called on a closed connection or
! * this Connection object is in auto-commit mode
* @see commit
*/
public void rollback() throws SQLException
{
+ if (isClosed())
+ throw new PSQLException(GT.tr("Cannot rollback when connection is closed."),
+ PSQLState.CONNECTION_FAILURE);
+
if (autoCommit)
! throw new PSQLException(GT.tr("Cannot rollback when autoCommit is enabled."),
! PSQLState.NO_ACTIVE_SQL_TRANSACTION);

if (protoConnection.getTransactionState() != ProtocolConnection.TRANSACTION_IDLE)
executeTransactionCommand(rollbackQuery);

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [NOVICE] Bug - DatabaseMetaData.getCatalogs() was [Novice] Can't get list of databases with \list

2009-11-03T10:39:54Z

On Tue, Nov 3, 2009 at 10:29 AM, Michael Wood <esiotrot@...> wrote:

> What does it do when you have multiple schemas (schemata?) in the database?

It returns a ResultSet listing all of the schemas:

Where is what I get when I tested it:

a
b
c
information_schema
pg_catalog
pg_toast_temp_1
public

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [NOVICE] Bug - DatabaseMetaData.getCatalogs() was [Novice] Can't get list of databases with \list

2009-11-03T10:29:08Z

2009/11/3 Richard Broersma <richard.broersma@...>:

> On Mon, Nov 2, 2009 at 1:05 PM, Christopher Frank <c.frank@...> wrote:
>
>>> > As for JDBC, there may be something that gives equivalent information,
>>> > but I
>>> > couldn't find it.
>>>
>>> http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html
>>>
>>> getCatalogs()
>
>> I had tried that but it only returned one database, the database to which I
>> was already connected. There should have been 3 others.
>
> I verified that the DatabaseMetaData.getCatalogs() only returns a
> ResultSet with the currently connect database rather than all of the
> databases in the PostgreSQL cluster.

What does it do when you have multiple schemas (schemata?) in the database?

--
Michael Wood <esiotrot@...>

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: Help with prepared statment for crosstab

2009-11-03T10:21:50Z

On Tue, 3 Nov 2009, Carl Shelbourne wrote:

> The SQL shown below works if I do not have any parameters, but when I add
> the parameters, I get:
>
> Caused by: org.postgresql.util.PSQLException: The column index is out of ra
> nge: 1, number of columns: 0.

The ? parameters you've used are inside a string literal, so they are not
considered parameters. Consider:

SELECT 'Does this work?';

The question mark is part of the literal, not a parameter.

Kris Jurka
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: Bug - DatabaseMetaData.getCatalogs() was [Novice] Can't get list of databases with \list

2009-11-03T10:16:15Z

On Tue, 3 Nov 2009, Richard Broersma wrote:

> I verified that the DatabaseMetaData.getCatalogs() only returns a
> ResultSet with the currently connect database rather than all of the
> databases in the PostgreSQL cluster.
>

The previous discussion to refer to is probably:

http://archives.postgresql.org/pgsql-jdbc/2004-01/msg00164.php

Crippling getCatalogs was the best proposed solution to the fact that no
other catalog based functionality existed (or could).

Kris Jurka

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Bug - DatabaseMetaData.getCatalogs() was [Novice] Can't get list of databases with \list

2009-11-03T09:36:56Z

On Mon, Nov 2, 2009 at 1:05 PM, Christopher Frank <c.frank@...> wrote:

>> > As for JDBC, there may be something that gives equivalent information,
>> > but I
>> > couldn't find it.
>>
>> http://java.sun.com/javase/6/docs/api/java/sql/DatabaseMetaData.html
>>
>> getCatalogs()

> I had tried that but it only returned one database, the database to which I
> was already connected. There should have been 3 others.

I verified that the DatabaseMetaData.getCatalogs() only returns a
ResultSet with the currently connect database rather than all of the
databases in the PostgreSQL cluster.

I see there was a previous discussion on this topic, stating that
Databases and Catalogs are not the same, so only returning the
currently connected database is correct:

http://archives.postgresql.org/pgsql-jdbc/2007-02/msg00112.php

However, calling the DatabaseMetaData.getCatalogTerm() function states
that the PostgreSQL's equivalent to a Catalog is a "database". For
this reason, it seems reasonable to me that getCatalogs() should
return a listing off all PostgreSQL databases.

If one really only wants the currently connected database,
Connection.getCatalog() will suffice.

--
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Help with prepared statment for crosstab

2009-11-03T05:15:21Z

Hi.

I have been asked to produce a report for a new game. The report needs to show the gamers unique id, gamer_number, his nickname, the average score of the best 5 scores he got playing the game during a specified period and a list of the top five scores that made this average.

e.g.:

gamerNumber;nickname;average;score1;score2;score3;score4;score5

91692656912;"nickname1";"14.33";29.85;21.03;7.38;6.73;6.66

The SQL shown below works if I do not have any parameters, but when I add the parameters, I get:

Caused by: org.postgresql.util.PSQLException: The column index is out of range: 1, number of columns: 0.
    at org.postgresql.core.v3.SimpleParameterList.bind(SimpleParameterList.java:53)
    at org.postgresql.core.v3.SimpleParameterList.setStringParameter(SimpleParameterList.java:118)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.bindString(AbstractJdbc2Statement.java:2155)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.setTimestamp(AbstractJdbc2Statement.java:3114)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.setTimestamp(AbstractJdbc2Statement.java:1358)
    at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.setStatementParameter(JRJdbcQueryExecuter.java:420)
    at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.setStatementParameter(JRJdbcQueryExecuter.java:255)
    at net.sf.jasperreports.engine.query.JRJdbcQueryExecuter.createStatement(JRJdbcQueryExecuter.java:230)

I am not too sure if this is possible, but I am trying to prepare a statement containing a crosstab:

SELECT
    gamehighscore.row_name[1] as gamer_number,
    gamehighscore.row_name[2] as nick_name,
    gamehighscore.row_name[3] as average_score, score1, score2, score3, score4, score5 from
    crosstab('SELECT ARRAY[g.gamer_number::text, pl.nick_name, (SELECT avg(tp.high_score) as myAvg
           from (select score as top_score from game_score t2 WHERE
           game_date BETWEEN ? AND ?
           and g.gamer_number=t2.gamer_number
           order by score desc limit 5) as tp)::text] as row_name,
           score::text as bucket, score from bet b

left join player pl on g.gamer_number=pl.gamer_number
WHERE g.game_date BETWEEN ? AND ? AND g.gamer_number=? order by score DESC limit 5')
as gamehighscore ( row_name text[], score1 numeric, score2 numeric , score3 numeric , score4 numeric , score5 numeric )

Running against Postgres 8.3.8 running on Windows XP. Tried with jdbc drivers 8.3-603.jdbc3 and 8.4-701.jdbc3

Is this possible? How do I escape the parameters within the crosstab? Is it the crosstab that is the issue even? Any help would be most welcome.

Thanks

Carl

This email and its attachments are intended for the above named only and may be confidential. If you have received them in error please notify the sender immediately and delete all records of the email and its attachments from your computer. Unless you are the intended recipient you must not read, copy, distribute, use or retain this email or any attachments or any part of them. Although we aim to use efficient virus checking procedures for emails and attachments we accept no liability for viruses and it is the recipient's responsibility to ensure they are actually virus free.

Re: Implementation of query timeout

2009-10-30T10:35:25Z

Dnia piątek 30 październik 2009 o 08:47:02 napisałeś:

> Radoslaw Smogura wrote:
> > I read a TODO list, and I decided to help a bit. So I've tried to
> > implement queryTimeout, currently ony for non-batch statements. You can
> > see code, at http://rsmogura.net/pgsql/pgsql_jdbc_querytimeout.tar.bz2
> > and analyze, chceck and test it.
> >
> > Small description how it works.
> >
> > 1. When the query is executed it checks if timeout > 0.
> > 2. If yes it creates TimerTask and add it to the queue, then sends the
> > query to server.
> > 3. On timeout and if statement hasn't ended cancelStatement is called().
>
> Maybe I am missing something there, but wouldn't it be much easier
> to send the following to the server:
>
> SET statement_timeout=<n>
>
> Then all statements that time out throw an exception with SQLSTATE 57014,
> and there's no need for separate threads and canceling the query.
>
> Yours,
> Lauernz Albe
>

Hello,
SET statement_timeout only set timeout for statement processing on server, it
not include the time of transfering data, which can be long for BLOBs. I've
found few posts that this is not enaugh solution "SET statement_timeout" from
above reasons. It's way those timeout is implemented in JDBC side.

Kind regards,
Radek Smogura.

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: Implementation of query timeout

2009-10-30T00:47:02Z

Radoslaw Smogura wrote:

> I read a TODO list, and I decided to help a bit. So I've tried to implement
> queryTimeout, currently ony for non-batch statements. You can see code, at
> http://rsmogura.net/pgsql/pgsql_jdbc_querytimeout.tar.bz2
> and analyze, chceck and test it.
>
> Small description how it works.
>
> 1. When the query is executed it checks if timeout > 0.
> 2. If yes it creates TimerTask and add it to the queue, then sends the query
> to server.
> 3. On timeout and if statement hasn't ended cancelStatement is called().

Maybe I am missing something there, but wouldn't it be much easier
to send the following to the server:

SET statement_timeout=<n>

Then all statements that time out throw an exception with SQLSTATE 57014,
and there's no need for separate threads and canceling the query.

Yours,
Lauernz Albe

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Howto retrieve a custom type via JDBC

2009-10-29T13:11:56Z

Hi,

I've created a custom datatype that I would like to retrieve via JDBC.
To make the problem more fun, the values are aggregated into an array.

The type definition is:

CREATE TYPE annotation AS ( namespace varchar, name varchar, value varchar );

The query looks something like this:

SELECT
node_ref AS id,
array_agg(DISTINCT ROW(namespace, name, value)::annotation) AS annotation
...
GROUP BY id;

I've hacked together some experimental code:

Array array = rs.getArray(2);
if (array != null) {
ResultSet arrayRs = array.getResultSet();
while (arrayRs.next()) {
PGobject anno = (PGobject) arrayRs.getObject("value");
// anno.getValue() returns the String "(namespace,name,value)"
PGtokenizer t = new PGtokenizer(PGtokenizer.remove(anno.getValue(), "(", ")"), ',');
if (t.getSize() != 3)
throw new RuntimeException("Could not read to annotation type: " + anno.getValue());
String namespace = t.getToken(0);
String name = t.getToken(1);
String value = t.getToken(2);
Annotation annotation = new Annotation(namespace, name, value);
}
}

The code above is not only fugly, but it breaks if there's a comma in
one of those values (e.g. (tiger,lemma,"1,62")). In this case, they are
4 tokens. BTW, the quotes around 1,62 are inserted by PostgreSQL,
they're not actually there in database. If PostgreSQL is smart enough
to insert the quotes, it should be able to correctly parse the string,
shouldn't it?

I got the idea to use PGtokenizer from looking at PGbox and stuff. But
my reason to create a custom type in the first place was to get to its
constituents in a clean way. Previously, I had simply concatenated the
strings with ":" and "=" in SQL and splitted them back into the
components in my Java code.

So, the question is: How to cleanly retrieve the components of a custom
datatype using JDBC?

Cheers,
Viktor

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Implementation of query timeout

2009-10-29T07:19:58Z

Hello,

I send this message again, because there were problems with my email address,
so it didn't reach mailinglist.

I read a TODO list, and I decided to help a bit. So I've tried to implement
queryTimeout, currently ony for non-batch statements. You can see code, at
http://rsmogura.net/pgsql/pgsql_jdbc_querytimeout.tar.bz2
and analyze, chceck and test it.

Small description how it works.

1. When the query is executed it checks if timeout > 0.
2. If yes it creates TimerTask and add it to the queue, then sends the query
to server.
3. On timeout and if statement hasn't ended cancelStatement is called().

I've used Timer to don't create multiple threads with each statement. The
AbstractJdbc2 have setQueryTimeout method, so DataSources and
PolledConnections can utilze it to set Timer shared for all connections.

The QueryExecutor has new method executeSynchronized (description in API). To
prevent termination on next statement & run statements in current thread, the
lock on QueryExecutor is needed (so no other thread will send other query
until cancelStatement is fully called). This method can be more usefull then
synchronized(...) block and can be used later.

Some new utilities class has been added.

The test code creates non tempolary tables to simulate long-run by creating
data lock on two transactions.

If the JDBC will go to Java 5, some of this code can use new
java.util.concurent API.

Kind regards,
Radek Smogura

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc