About concurrence management in JCo Connections

[Former Member]

Hi everybody.

While still developing Java-based applications for retrieving BAPI structures and tables, I got an issue:

What should be good and generic practices for managing the concurrence in a JCo-based application?

The reason of my issue is: I have some apps that make transactions with the BAPI structures and tables, such as insert-update-delete basically. And my apps are planned to be used by more than one user. So I don't wanna have a situation when two users simultanealy would make an update to the same BAPI structure or table.

I think that an ABAP_AS_POOLED connection could deal with this situation, specifying parameters like the JCO_POOL_CAPACITY and the JCO_PEAK_LIMIT. Also we have the SessionReferenceProvider interface for a multi-threading enviroment, but as far as I'm concerned, this interface only works when the function called include the Z_INCREMENT_COUNTER and Z_GET_COUNTER functions, according to the SAP_JCo_Doku_3.0_EN.pdf. And the matter is that several of my called BAPI functions don't include (or don't have, or aren't allowed to use, not sure) those increment functions.

So I would like to know if there is a way to optimize the concurrence in a generic JCo multi-threading enviroment. If no, I think I must implement manually a Java-based multi-threading scenario, specially for my increment-less functions.

If you have ideas or suggestions, please share!

Thanks.

[Former Member]

I'm not sure how to answer your question, because it's a bit generic and you don't provide details of what you want to achieve. So let me give you a generic answer...

It looks like you're talking about concurrency in a JCo client program (talking to a SAP backend). Also, you are mentioning multiple users, so it seems that you're not concerned about the usual Java concurrency problems one immediately thinks about (which we fix via introducing synchronization or atomic updates).

If you are executing an RFC function in SAP, that function should already have mechanisms built in to handle concurrency. I.e. the function should use the SAP enqueue system to set logical locks to prevent concurrent updates to the same data (see for example the [SAP lock concept|http://help.sap.com/saphelp_nw70ehp2/Helpdata/EN/47/df116e6abf296fe10000000a42189b/frameset.htm] for details on locks in SAP).

If for some odd reason the RFC functions you call don't have any locking logic, you should have two options: You could either add the locking logic in SAP or alternatively try setting the lock entries in SAP via calls from your RFC client (I'd try to avoid the latter).

Also we have the SessionReferenceProvider interface for a multi-threading enviroment, but as far as I'm concerned, this interface only works when the function called include the Z_INCREMENT_COUNTER and Z_GET_COUNTER functions

I haven't checked the example (I was to lazy, because it was too long), but if my memory serves me correct the example was quite complicated, because it introduced concurrency in the client application via threads and sessions had to be maintained across threads. The called functions *_COUNTER where just examples for any RFC function that you could call, which would have some state (i.e. requiring stateful calls as opposed to the default stateless calls JCo3 does).

There is no need for a SessionReferenceProvider as long as each of your threads invokes all RFC calls en bloc, i.e. if each thread has all RFC calls wrapped into a JCoContext.begin()/end().

If this doesn't answer your question I suggest you post some further details.