You may create a thread to call your own code or the dbop class but not the data node, which is a servlet. It's doable.

Wonderful !
It works fine :wink:
But I have some doubts ..
I used the class created by the runtime (dbop class) within a thread and I called upon the execute () method.
The thread that executes the call is created by a parent process that waits for the maximum time set by me. At the end of the timeout, the parent process checks to see if it was properly set the output variable associated with the class dbop. If the output is not empty, then the procedure has answered correctly, otherwise it could have happened somewhere else (the stored continues to run but now my timeout has expired, or there is some other exception, however, I can manage. .)
According to you, there are problems with the JVM / DD runtime by using this management.
Keep in mind that the call load is very high and I would not want the number of threads created would send crash tomcat!
Regards

You need to make sure the thread you create can always exit otherwise you would have hung thread, in which case in heavy load, you lead resource and cause the app server to crash. OD has no management concerning the these threads you create. It's all at your own discretion.

The problem is born precisely because , in these particular cases, when a procedure for some reason does not respond , the system was stalled. So in theory I am not able to make sure that the threads that are waiting to be completed within a certain period (I guess after a few minutes you think the oracle driver to break the connection). But what I could not verify it works correctly and is managing the pool of tomcat . If I have eg 10 connections can be used , and all 10 are to be stalled, using this approach (ie, using the class dbop within a thread... ) can also pemettere to 10 calls to continue because I can simulate the procedure I responded with an error. As for the maximum number of threads that remain blocked .. should correspond to the parameter ' maxActive ' pool tomcat (in this example 10). All calls that come while the ' maxActive ' are stalled , waiting for just the ' maxWait ' and ending correctly the thread that uses the class dbop (it is in fact caught the exception " com.avaya.sce.runtimecommon.SCERuntimeException : No failover configurationorg.apache.tomcat.dbcp.dbcp.SQLNestedException : Can not get a connection , pool error Timeout waiting for idle object ..... "
Regards
Marco

Using threads is never recommended in OD. It would not automatically solve any problem, and it is not a trivial task for a lot of developers. In most of the situations, it is not necessary. In your case, you would hope to move on to the next node while a stored procedure is called asynchronously. However, if the stored procedure call is taking a long time and keeping the thread waiting, you have no way to stop the thread. In heavy load, you would have all these threads hung. I would say you need to go back to the basic. You would need to find out why the stored procedure call would stall. If it happens a lot, you need to fine tune it. Or maybe it's because the network is not stable. You may need to look at that problem as well. If it's just a situation in heavy load, ask if your load test is reasonable given the resources you have or you may need to scale it.

I am fully agree with your analysis. The timeout problem in the procedure is very rare, but this procedure is concerned with the recognition of the caller and our client asked us to handle these cases. Unfortunately to handle these few cases I will have to make perform this procedure using the thread as described previously, and this obviously for all calls .. The important thing for me is that this way of calling the procedure causes no crach at runtime (so also in the case of normal operation of the procedure that usually takes a few thousandths of a second).
You summarize the steps that I will use (sorry but it is very important that the systems do not entru suddenly stalled ...)

1) I create a thread in the node 'Servlet' (the thread has the method 'run' synchronized)
2) Start the thread (method 'start')
2) The run method of the thread instantiates the class 'dbop', executes the procedure (method 'execute') and waits for the procedure to end
3) the main flow that started the thread, the thread waits for closure in a synchronized block up to a maximum of 5 seconds
synchronized (this)
{
this.wait (5000);
}
4) The thread that executes the procedure calls the method notifyAll () as soon as it ends 'execute'

PS
By doing these tests, I also noticed another incredible scenery ... After calling the method 'execute' call remains suspended is if the procedure takes a long time but even if you suddenly die .. .. the connection with DB!

As said earlier, the thread will get stuck waiting for the stored procedure to return no matter what. So this is not going to solve your problem.