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