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.

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.

I think pooling would be a better idea, but I had not done that before and would like to get some directions if any of you had come across enabling pooling before.

First it would be more clear if you specify wich Context are you using? IS Java API or IS C API. But looking at your post it mentioned java so I assume you are using Java API.

It is correct Context doers take time and invoke is fast. I am not sure what you mean by :making Context static? But what is normaly done with COntext to get high performance is simply reuse the Context object and connection. You simply create context, connect to IS authenticate with user password and then perfom as many invokes to IS as you like.

The PROS: 1. speed (you can get around 300-600 invokes per second easy depending on the hardware and network.

CONS: 1. You are using same session for all invokes

It seem my response got cut off:)

Continue:

CONS: 2. Development is bit more complex since you have to reuse Context object.
3. If your client starts leaking memory with creating Idata object example your application is risking to run out of memory fast on same context.

I did some testing to these IS API before and can say that IS Java nad C APi is fastest way to invoke services on WM IS! Its much faster than Broker C/Java API forexample. However, if you have to use Context and connect on every invoke you can get max 3-7 invokes per second. Setting up Context itself as object is not so expensive but connect is expensive operation!

Thanks Ian for the response.

Your guess about the IS Java API is correct. I missed to mention it.

In my case I have only one invoke to make, so I cannot make one connection and make multiple invokes in it. Only one service need to be invoked when the jsp page is accessed. The problem is, this page is going to get thousands of hits. This should make that many invokes, so I was wondering how could I avoid making this connection for every tries and keep the connected object alive so that subsequent connection can just call using this “connected” object.

Something like a database pool, but I do not know how to do it. Can you shed some light on this pls.

Thanks

Thahir

Tahir,

The most obvious choice would be to go with a hybrid approach. If you create a static then you are left with one Connection to work with for all your requests. And that may not be enough if the number of hits is very large.

So I would suggest create a pool of connections and retrieve an available connection from the pool everytime you need one and return it to the pool after using it. This will still have the problem that you will be using the same session for multiple requests but since you are making these calls from the web server I dont think you care about webMethhods sessions anyway. They would only come into play if you have stateful services on the webMethods plaform.

Rupinder

Tahir,

I replied for the same in wmusers. Yet here the scenario is more clear that you want only single invoke for each call to JSP and I assume that they are not from same user in the same session. So, to have Connection Pool is the best.

You can implement connection pool in your java class (servlet). The number of connections to be kept alive will depend on the JSP page hit rate and time taken for the invoke() to return.

To implement the connection pool, I suggest to have a servlet which will have init() and destroy() methods to initialise and drop connections. You will need two synchronized methods in this. Detailed below.

1. In the init(), create as many connections needed and keep them in a HashMap(pool) with running numbers as key.
2. Have flag(int) to hold the index of next available connection.
3. Context synchronizedGetContext():
   Returns a Context of available.
   Before returning increment flag (Flag+1).
4. boolean synchronizedReturnContext(Context cxt):
   Put this context at Flag-1.

should be incremented in a synchronized method, to avoid two different requests manipulating the flag at a time.
4. YourMethod() containing invoke() need not be synchronized.
5.

Tahir,

By mistake before I completed the message got submitted.

Ignore the last 3 lines.
Continued below from 4:

4. boolean synchronizedReturnContext(Context cxt):
   Put this context at Flag-1.
   reset flag to this index.

From JSP you can get Context from this java class. Also you can improve on the above to auto-grow the available pool size based on demand.

HTH

Thank You Rupinder and Krishna

I am sure connecion pooling is the right way to go. I had started working on it and appreciated the inputs given by you all.

Thank you again for the time and consideration.

regards

Thahir

I am having probelme to get the connection from adpater connection pool. As