views:

133

answers:

3

Is ResultSet Thread safe?

My question arises because in my program i have used different statement for each query i have declared a ResultSet as an local variable but it gives me a error of Operation not allowed after ResultSet is closed. But my statements are working as i'm using the statements in insert and delete query.I have commented the ResultSet part and have not got the error !!

+2  A: 

No, ResultSet should not be exposed to more than one thread.

A ResultSet should never have a scope larger than a single method: execute the query, map the ResultSet into an object or collection, and close the ResultSet in the same scope in which it was created.

The correct way to close a ResultSet is in a finally block in its own try/catch.

Looked at the code in your other question. It needs a serious, complete refactoring. It's not surprising that you're having problems with it. Here are a few suggestions:

  1. Follow the Sun Java coding conventions. It might seem trivial, but anything that makes your code harder to read is a bad idea. Your "doComms" and "savetodatabase" classes break the "class names start with a capital letter" convention.
  2. Naming matters. "doComms" is not my idea of a good abstraction.
  3. Magic numbers/constants are everywhere. They'll make your code harder to change later.
  4. Java's an object-oriented language; you're writing in another style altogether. When I see "insert studentinfo", it makes me wonder where the Student class is.
  5. Your JDBC code doesn't handle resources properly at all.

Just curious - are you trying to learn how to write a server? Is there a reason why you wouldn't use a servlet engine as the basis for this app? Sockets are a very low level place to start to solve a problem like this.

duffymo
yes i'm trying to write a server ...thanks for the reply.
+1  A: 

The real problem is that you are sharing Statement objects between multiple threads. Each time you "execute" a Statement, the previously returned ResultSet is automatically closed. In this case, the ResultSet objects "belong" to a different thread which may not yet have finished using it. Hence the exception ...

You should not share Connection, Statement / PreparedStatement or ResultSet objects between multiple threads. Each thread should acquire and release its own resources.

Stephen C
but wouldnt making a connection for each thead led to many connection and closing it evrytime lead to overheads
Not if you use a connection pool. Besides, an inefficient solution is better than a "solution" that breaks due to concurrency bugs.
Stephen C
how do u rate proxool for connection pooling? is there any better tool that can be used??
Read the answers to http://stackoverflow.com/questions/520585/connection-pooling-options-with-jdbc-dbcp-vs-c3p0
Stephen C
+2  A: 

The few times I've written hand-coded JDBC, it's been both ugly and error prone. Of course, that could just be me, but you may have much better results with using the Spring JDBC data access classes. You don't have to use the whole spring container, just a DataSource and a spring's JdbcTemplate class.

It enforces a usage pattern to JDBC that is both thread-safe and resource-safe.

mdma
Agree with this. You are reinventing the wheel, badly. I am all for teaching people how not to shoot themselves in the foot, but can only do so much at once.
bwawok