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.

Pradeep,

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

protocol

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

login

and

disconnect

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

events

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:

If there is a security manager, its checkConnect method is called with the local host name and -1 as its arguments to see if the operation is allowed. If the operation is not allowed, an InetAddress representing the loopback address is returned.

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).