> Even the documentation for 'BlockingQueue' makes that point: "BlockingQueue
> implementations are thread-safe." Not the interface, only its
> implementations are thread safe, and implicitly only the ones known at the
> time the Javadoc comments were written.
Of course BlockingQueue does not *provide* thread safety, but it
*requires* it of its implementations. Not through any enforceable
means, but this is part of the interface contract, i.e., this is part
of what it means to be a BlockingQueue. Following the thread safety
guarantees (or lack thereof) specified in the interface contract is as
important as having put() actually put an item on the queue instead of
removing one (note that this is also not "required" by the interface).
Implementing an interface is more than just adding "implements Foo"
and writing whatever code you like in all the methods required to be
there by the compiler.
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).
So, any thoughts on Florian's suggestion?
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com