I’m debugging a java service that someone else wrote. The symptoms lead me to beleive there is a threading problem. It is possible to put a synchronize clause on the IS server java service? The routines we are calling (supplied by SAG) JADABAS don’t appear to be thread safe. And of course getting the vendor to change their interface could take a long time.
Thanks in advance for any help!! Sincerely, …Kevin
It’s difficult to respond without more details but…
Are you clear that when invoked, your Java service is running as a static method, and the implications thereof?
So the question is… do you really need synchronization within the Java service ( with it’s potential performance problems ) or do you just need to create an independent object instance on each Java service invoke with independent data?
I’m not positive which I need. From what I’m seeing the vendor supplied jars (SAG) they appear to have static variables that should’t change during execution. Running threads one at a time against it, it apears to work just fine (test java application), but when I run it from within webMethods, it producing symptoms like threading problems. The vendor has given us a way to trace their execution. And in the trace we’ll see things like; open, select, open, close select close. So it appears if the multiple threads are causing problems. If I run it in a single threaded test application, I get the exepcted sequence: open, select, close, open, select, close, etc. Leaving the connection open isn’t a solution, their software will croak after x amount of inactivity. I’d be willing to take the performance hit on the synhronization. Or at least be willing to try it (if possible) to see what happens.
Any suggestion on how to do that? Thanks in advance!
You said you created a single-threaded test application.
What happens if you create two of them, and make one sleep before doing the select. While it is sleeping, start the second test program without the sleep. If the second program completes, and after, when the first program wakes up, it completes its open/select/close sequence without error, you have proven that the jadabas jar is thread safe (at least in this case).
If this is the case, you only need to create a new object instance in your Java service to perform the interaction with jadabas. So after getting your data out of the pipeline, your Java service would do something like [ new MyClass(parm1,parm2).talkToAdabas() ]. Needless to say, in MyClass, the variables that store your connection info from Jadabas should not be static!
I’ve seen the Integration Server get locked up in handling synchronization of it’s own threading. Try not to add to this risk with your own code.