Re: PSQLException: The column name <col> was not found in this ResultSet.

I am using the Spring Batch project
(http://static.springsource.org/spring-batch/) to complete a large, parallel job
configured to run 10 threads.
A org.springframework.batch.item.database.JdbcCursorItemReader<T> object is
used to open the recordset using TYPE_FORWARD_ONLY and CONCUR_READ_ONLY. I
tried following the code but was unable to figure out exactly how the recordset
object was accessed and where.

It does sound like the root of the problem lies in Spring Batch not properly
synchronizing access to a recordset object and they should address the issue
there if possible. While I would like to see the issue in PostgreSQL JDBC
driver addressed as it was the only problem I have encountered to date, I
understand if it is not since there is no explicit thread safe guarantee around
a recordset.
Thanks.

Michael

----- Original Message ----
From: Kris Jurka <books(at)ejurka(dot)com>
To: Maciek Sakrejda <msakrejda(at)truviso(dot)com>
Cc: Michael Fork <mfork00(at)yahoo(dot)com>; pgsql-jdbc(at)postgresql(dot)org
Sent: Sun, November 14, 2010 5:44:33 PM
Subject: Re: [JDBC] PSQLException: The column name <col> was not found in this
ResultSet.

On Sun, 14 Nov 2010, Maciek Sakrejda wrote:

> But we're getting really off-topic. Samuel suggested that the
> ResultSet interface does not guarantee thread safety (i.e., it does
> not promise that any implementation will be synchronized). As Till
> pointed out, the PostgreSQL implementation JDBC API *does* in fact
> promise thread safety (which is fine--an implementation can offer
> additional guarantees here, as per Hashtable and Map). This would
> suggest that we do need the fix that Michael originally suggested.
>
> However--and I think this is the only real open issue--Florian pointed
> out that the guarantees in the PostgreSQL JDBC docs could be
> interpreted to mean that the PostgreSQL Connection is guaranteed to be
> thread-safe while ResultSet is not (especially given the dicey
> wasNull() issue).
>

The real question is how realistic/useful is the coding pattern in question.
There are other known thread safety problems in the driver that have not been
dealt with. For example two threads sharing a PreparedStatement, one executing
it while the other is simultaneously calling setXXX on it. The driver could
synchonize this, but you'd random behavior behavior depending on which call
happened first. So no driver changes were made to help support this because it
doesn't seem like a reasonable coding pattern.

Perhaps Michael could provide some additional context regarding the application
and why multiple threads are processing the same ResultSet. You can avoid
wasNull problems by only using getObject, but you'd still need to synchonize the
next() calls. And how much gain can you really get by parallel ResultSet
reading?

Kris Jurka

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