Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link

Dave Michels

+ Follow
since Mar 29, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Michels

The key in what you're doing is that you need to be sure that you close the ResultSet that is returned from each query after you execute it. You're correct in that you don't need to close the PreparedStatement after it's initially compiled (prepared). You are also correct in that you should only need to set the bind variables on subsequent loops and re-execute the statement...At least this is the *typical* behavior for most JDBC drivers (you didn't specify which you were using).

Each result set corresponds to an open cursor in the database, so when you loop through and execute your PreparedStatement repetitively w/o closing the ResultSet you leave an open cursor for each execution.

If you call the java.sql.ResultSet.close() method within your loop after you're finished retrieving the values, prior to re-execution, you should be able alliviate the open cursor issue that you're incurring.

It apprears that your client doesn't have the correct IntialContextFactory configured for the JNDI environment based on the exception stack trace. See the following Glassfish Naming Factory Env

and see if that helps.
Do you have any messages on the MQ side associated with this client connection being dropped?

Also, is there a firewall between you and the MQ server?

Any more details in the stack trace?
It sounds like what you're trying to do would constitute deriving your own


for the exchanges between your client's and server.

If you think of it like a JDBC connection. You don't manage/interact with the underlying TCP connection as the drivers do so for you and negotiate the vendor specific protocol so things like




are handled (Hence, why it's so important to call the close() of the java.sql.Connection when the process is finished using it). In order to manage these different


that can occur through the connection, you will likely need define something of a message protocol (if you haven't already) that denotes the type of message being sent over the connection. That way on the client side, when the client exits or disconnects, you can send the appropriate message to the server indicating that you want it to terminate any thread associated with that client (i.e. clean up any server side resources).

Hope that helps a little...
If you check the JavaDoc on this method you can see the following:

It could very well be a case of the above, and a difference in the configurations of the security managers across the OS's (and possibly versions of the JRE that is being used).