5

I did not really manage to find proper documentation about this. There are the classes in JCO com.sap.conn.jco.JCoDestination and com.sap.conn.jco.JCoDestinationManager. My questions about them:

  • are they thread safe?
  • if not, are they expensive to create?
Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Gábor Lipták
  • 9,646
  • 2
  • 59
  • 113
  • 1
    The advice I've seen is that if the documentatino for some code does not say it is thread-safe, you should assume it is not. – Raedwald Nov 11 '11 at 17:02

3 Answers3

2

I think I have found it finally. http://help.sap.com/saphelp_nwpi711/helpdata/en/48/6437ccbdbc51eee10000000a421937/content.htm

CAUTION In a multi-thread environment, distribution of objects (for example, JCoTable objects) between different threads must be implemented carefully. Note that it is not possible to make multiple concurrent SAP calls for the same direct connection.

So its not thread safe

Gábor Lipták
  • 9,646
  • 2
  • 59
  • 113
  • Differentiate between whether the instances are threadsafe and whether the _class_ is; describe whether it would be an acceptable workaround to have one instance per thread. (I know of some systems that use this model, but don't know SAP at all.) – Donal Fellows Nov 11 '11 at 15:26
  • The problem is that we currently have a class which is a spring singleton, and it is called for every RFC call, and this class has two member variables with the mentioned two class. For any operation this two instance is used. I dont think its ok, since the examples in SAP documents always use local variables for destination objects. – Gábor Lipták Nov 11 '11 at 20:27
  • 1
    You could try using a different lifecycle I suppose, such as `prototype` or `session`. – Donal Fellows Nov 11 '11 at 23:22
1

One cannot say for the whole JCo framework that it would be thread-safe or not. It depends on the used classes and instances.

Data container instances in JCo like JCoFunction, JCoTable, JCoStructure and JCoRecord, are not thread-safe - luckily, because usually they are not accessed from different threads simultaneously, so not automatically synchronizing these instances leads to better performance.

But classes and static methods are thread-safe in JCo. You do not need to synchronize calls to the JCoDestinationManager, for example.

And with JCoDestination it's a special case. Usually you don't need to synchronize your calls to this instance because it will internally create and use distinct RFC client connection objects for each session. In JCo's default implementation every thread is treated as separate session, so you cannot get into trouble with the thread-safety here. Only if the infrastructure environment registers its own SessionReferenceProvider at the JCo runtime and would assign the same session ID to multiple threads at the same time, then there might be thread-safety conflicts for stateful RFC calls to the same destination. In this case JCo detects such an error situation and throws a JCoException with error group JCO_ERROR_CONCURRENT_CALL.

Trixx
  • 1,796
  • 1
  • 15
  • 18
0

Have you read the documentation of connector?

https://websmp105.sap-ag.de/~sapidb/011000358700000730362009D/SAPJCo_Doku_3.0_EN.pdf

I don't understand your question, you try to call a RFC and you have not achieved?

openyourstackoverflow
  • 94
  • 1
  • 6