Samuel Gendler wrote:
>>> Code which utilizes a
>>> ResultSet should do so in a thread safe manner, rather than attempting
>>> to make the resultset implementation thread-safe - unless my assumptions
>>> about the intent of the interface designers is incorrect.
Lew wrote:
>> It is meaningless to talk about thread safety with respect to interfaces.
Maciek Sakrejda wrote:
> I think Samuel was talking about the thread-safety guarantees of the
> interface contract. E.g., the List interface does not guarantee
It is meaningless to talk about thread safety with respect to interfaces.
Thread safety is an implementation guarantee (or lack thereof), not
discernible nor enforceable by an interface.
> thread-safety, so if you want to call add() on multiple Lists from
> multiple threads, synchronization is your responsibility. If the
If you want to call 'add()' on multiple 'List's from multiple threads, even if
you are using thread-safe implementations, if the actions among the several
list instances needs to be coordinated then synchronization is your
responsibility.
> interface contract of ResultSet does not guarantee thread safety, I
Because interfaces cannot guarantee thread safety.
> don't see why the driver should bother to offer it there. Hashtable,
> Vector, and StringBuffer took that route, and look at them now.
Those are not interfaces.
It is impossible for ResultSet to guarantee thread safety. It is also
impossible for List to guarantee thread safety, yet
'java.util.concurrent.CopyOnWriteArrayList<E>' is a "thread-safe variant of
ArrayList".
Thread safety lives or dies only in the implementation.
--
Lew
