Expert opinions required pls.

Would it be true that Context.connect is an expensive operation and context.invoke is done much faster if the context was there all the time. I mean like a static object or something. Would it be thread safe to do so.

Thahir

Thahir,

The Contect.connect function sets up the initial connection. This creates a session on the Integration Server and gives the client a reference to this connection. So indeed, reusing the same connection for several invokes will have a positive impact on performance.
I never heard of any issues with threads when using this method. Make sure you call Context.disconnect after you finished invoking services (and in your catch blocks) so that the server session is closed when your client finishes. Otherwise the server session will only close after the timeout period which will cause the server to consumer more resources than necessary.

Regards,

Koen

Depending on your requirements, a more sophisticated model using code to maintain a connection pool might be useful. In that case, the code would keep, say, 5 connections alive at a time and user code would “request” a connection to use. This would be able to contain more robust synchronization code, if needed. I haven’t heard anything positive or negative about the thread safety of the Context object.

However, if you’re just looking to optimize a relatively infrequently executed sequence of calls, indeed it’s better to minimize the number of connects/disconnects used:

Context.connect()
Context.invoke()
Context.invoke()
Conextt.invoke()
Context.disconnect()

Koen, Tate

Thanks for the response. My scenario is where the service is getting called thru a java class from the web. The hits expected on this page is very high, causing many calls to connect, invoke and disconnect. I was wondering cant I just avoid, the connect and disconnect part all together by making context object as static or something, never disconnect it. What would happen in this case.

Tate, yes I too thought pooling would be a better idea, but I had not done that before and would like to get some directions if you had came across anything like this before.

Thanks again

Thahir

Thahir,

In terms of the static object, just try it and see. I don’t know of any instances where that’s been done, so it may or may not work. You might also want to try the threaded invocation to help with performance.

As for the connection code, I haven’t done it before–just suggesting it as an option if you run into multi-threading or performance problems with the first method.

Gurus

I need some help here to make my java client “pooling enabled”.

or

some way to create a context object, make a connection and “preserve” this “connected” object so that it is available (like a static object) as long as the server is up.

In other words, I want somehow to avoid creating a context object and connecting using that object every time in my java client

Your valuable insights are highly appreciated

Thahir

From your description, I’m assuming you’re on an app server of some sort and connecting to IS from there. As Tate mentioned, a connection pool is most likely the way to go. There are lots of examples and source on the web for managing pools, be it HTTP, JDBC, threads, whatever. You can use the constructs to create a Context/TContext object pool. The pool would handle threading nicely and you could control the number of pool connections to make available.

Here are a couple links to get you started.
[url=“Oracle Java Technologies | Oracle”]Oracle Java Technologies | Oracle
[url=“http://www.devx.com/Java/Article/20891”]http://www.devx.com/Java/Article/20891[/url]

If a pool seems to be overkill (though it probably really isn’t in an app server environment with lots of users), you might create a class to manage the connection and instantiate it when your app is loaded on the app server. You’ll need to be attentive to threading issues so that only one thread is using the connection at any given time.

Thanks Rob

As usual u r a great teacher.

Let me start reading now and do some homework, before I come back again.

Thahir

We did something similar recently using webMethods Portal. We needed to create a portlet that used a BrokerClient object to communicate to the webMethods Broker, but didn’t want to reconnect each time the portlet was instantiated (in fact that would have defeated the purpose of connecting to the Broker in our case).

The solution was to create a simple portlet that subscribed to the Portal event associated with user logins. That portlet created the BrokerClient object and stored it in the Portal user’s session object using an API command.

The portlet that actually needed to communicate with the Broker retrieved the BrokerClient object from the session in it’s init() method and did its work.

The BrokerClient cleanup was performed by a portlet that subscribed to the Portal event associated with user logout or session timeout events.

I know you’re working with an app server rather than with Portal and are creating IS Context objects rather than BrokerClient’s, but it seemed relevant. You should be able to do what you need with pooling in an app server or by storing your Context objects in the user’s session object.

Mark

Hi Thahir,

Context.invoke() is not thread safe. Context.connect() is a static method, which returns a new connection context. So if your java class makes calls single Context.connect() and the method which encapsulates the Context.invoke() is not synchronized, it will not be thread safe.

Hence, if you expect high hit rate, it is good to have Connection Pool. Else, you can make Connect and Disconnect for each call.

HTH

Thanks GPM, Mark, Rob, Tate, Koen,

I had gone ahead and created my super duper context pooling. Thank you gentlemen for your valuable time and response.

With guys like you around, life is beautiful

Thahir