JCA Performance

[Former Member]

I'm developing a JSP DynPage using JCA to access RFMs in R/3. The JSP DynPage model is basically: doInitialization

then iterate through doProcessBeforeOutput, doProcessBeforeInput, and react to any event processing triggered by JSP. And, use a bean to store any persistent data.

My question is this as it relates to JCA: for a high volume environment, is it better to acquire a ConnectorService, ConnectionProperties, Client, etc. during doInitialization and store them in a bean for reuse, or acquire them each time ( in doProcessBeforeOutput for example)?

All the examples I've seen thus far perform the latter, but I would like to know if this is the recommended approach. I haven't been able to locate any documentation which describes the overhead associated with JCA session management.

Thanks.

Mark

[pravesh_verma]

Hi Mark,

Yes the good practice for acquiring the ConnectorService, ConnectionProperties, Client etc is durind the <b>doProcessBeforeOutput</b> fucntion. The reason is very simple, when you create a bean in the doInitialization and store the service objects for future use then in the large volume environment it can lead to resource inavailablity state.

These objects will be in use since they are allocated to the class that is still running so it cannot be used by other services. If the class which has stored these objects in the bean is not using these service objects then its just a wastage of saving them for it. In the mean time these service object can be allocated to some other resource.

So its better to aquire these objects when ever we need them and then free them when we are done. This is the same concept as that of pooling.

I hope this will help you.

Regards

Pravesh

[Former Member]

Thank you both for your responses. They were very helpful.

[Former Member]

> is it better to acquire a

> ConnectorService, ConnectionProperties, Client, etc.

> during doInitialization and store them in a bean for

> reuse, or acquire them each time ( in

> doProcessBeforeOutput for example)?

Personally, I wouldn't hold any of these references.

The connection object itself is pooled, so the overhead of getting the service and asking for a connection for each request with a backend query should be rather little.

Regards, Karsten