Java EE / GlassFish - Threads and connections

Scenario:

I have been using Java SE for quite some time, working with threads etc, though I have little experience with Java EE.

I have a 3rd-party Java library that connects to a remote server (at the 3rd-party company). The library creates several threads and is keeping the connection alive by itself. I am not allowed to open new connections over and over (by c开发者_Go百科reating new instances of the library). I need to keep the same instance of the library which will keep the connection up at all time.

This is quite easy in a Java SE application.

Now, I want to create a web service (perhaps using GlassFish or similar) to use internally at my company to be able to use the functionality of this library with its connection. In other words, I need a custom remote connection (that is not created by or managed by my code) to be kept alive between request instances.

Question: Is this possible to achieve? If so, which technology should I take a look at?

you can do that using connection pool.when ever a connection required to remote server, get the connection from this pool instead of instantiating every time.This will help you in maintaing better memory foot print and efficiency.If connection is no longer in use, you can return the connection to pool.

I have recently implemented a similar system, using Tomcat as the Servlet Container and Metro 2.0 as the JAX-WS implementation. My service maintains socket connections to backend components (implemented in C++) and communicates with them using a proprietary network protocol.

I used a 'Component Manager' thread to manage the high-level communication with the Components (connection establishment, handshaking etc.) and a 'Network Selector' thread that managed the actual communication with the Components. This 'Network Selector' used asynchronous non-blocking sockets using the Java Socket Selector family of classes - using a single thread to interact with the Socket Selector class is an important point as some Java platforms exhibit bugs when multiple threads are used.

It's working very well so far, so I can tell you that it's certainly possible. If you require any clarification then please post here or e-mail me (see my profile).

You need to have a factory maintaining the connections, and then provide it through JNDI in the same way that e.g JDBC connection pools are provided.

You then need to ensure that the connections are returned to said factory and then integrate it in the application server life cycle so that it is pulled up and down programatically.

Note that there is a nasty classloader problem lurking here if you are not careful. You will have to have a common class to the factory and the clients and if it is not one in the standard runtime library you will need to figure out a way to have it correctly shared unless you want to use reflection to get to the methods.