1) I have looked at the API for javax.sql.DataSource and ConnectionPoolDataSource, but I am unsure as to whether these interfaces(and corresponding implementations) are thread-safe.
I am planning a singleton which will cache the DataSource in an instance variable of the singleton, but I need to make sure that Datasource is thread-safe.
2) In general, if the Java API does not explicitly state whether a class/interface is thread-safe or not, can I assume that indeed it IS Thread-SAFE?
1) That depends on the particular implementation (JDBC driver), of course. I've done that with DataSource successfully some time ago (with Oracle 8.1.6 driver in Bea WLS 5.1 and IBM WAS 3.5)
2) Nope, you can't.
Thanks for responding.
You say that you cannot assume a class is thread-safe just because there is no mention of it in the JavaDoc - In some of Sun's APIs, it explicitly talks about threading issues. For the classes that do not contain an explicit statement, how can I find out whether these are thread safe or not?
particularly, I had interfaces in mind. Most of the J2EE API (or javax.sql in your case) is comprised of interfaces, not implementations. You'll never find statements about thread safety of implementing classes in the Javadoc of the interface (sadly that's not part of the interface contract in Java). Sometimes you may find that information in the specification of the corresponding API, but most times you won't. In the latter case you have only 4 options:
1) Look at the documentation of the implementing vendor
2) Look at the source code (or decompile it, if you don't the have source)
3) Provide your own threadsafe wrapper around the API if that is feasible
4) Reconsider your design (do you really need a threadsafe implementation?)
When programming against interfaces I feel it is often bad practice to rely on threadsafety of a particular vendor's implementation when other vendors' impls might not provide that guarantee.