conn.close() is sufficient. Not setting conn to null will not prevent the pool from handing out that connection again. According to my knowledge, the statement conn == null is superflous and unnecessary, if somebody can point out why its required I will have learnt something new:)... Cheers, Sohil
The reason you should set your variables to null is defensive, not offensive. How do *you* know that the connection pool is going to hand out the connection instance again, instead of closing it and throwing it away? For example, I know of some connection pools that decide a given connection is only going to be good for X amount of time, so when it is "closed" after that time is expired, the pool will do a *real* close() on it, and then acquire a new live connection from the database later.
(Interestingly, if you're in to how web servers work, the Apache HTTPD server version 1.3 plays exactly this sort of game -- it has an upper limit on how many responses should be generated by a single server process instance before this instance is thrown away. I'd guess this was originally done to minimize the impact of memory leaks.)
If you hold on to a persistent reference to the old connection, you've just disallowed the garbage collector from recycling the old object in this scenario.
Of course, if "conn" was a local variable inside a method that's already returned, you're absolutely correct ... the reference is no longer "live" (from the perspective of the connection pool) once the method has returned. However, it doesn't hurt to explicitly indicate that you are now-and-forevermore through with the old reference.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
