Comentários (13)

1 gree comentou às Link permanente

Good article..The last link 'SCA timeouts'. Is it correct?. Couldn't find anything useful there

2 Lalitha_Chandran comentou às Link permanente

Thank you for pointing it out. The link is fixed now.

-Lalitha Chandran

3 irismar comentou às Link permanente

It is what I am trying to find right now!
Thank you very much for your information.
By the way,I heard that this is the Java nature , the passive nature of transaction timeout.
If you have the back data about the fact that this is standard by Java, would you please add the information as well?
I didn't check the links you've commented above yet so if I find the information I'll comment as well.
Thanks again for your good work!

4 Lalitha_Chandran comentou às Link permanente

Hello Irismar-

Thank you for commenting on the blog and for the encouraging words.
Here is a link I found, which answers your question the best. Its from an older version, but still holds good.
The Transaction Service itself cannot raise an exception for the application because the timeout detection is done on a different thread to ensure that the timeout is detected at the correct time, and Java™ does not allow one thread to raise an exception on behalf of another thread.
Please refer to the below article on Java Thread.stop method:
Hope this helps. Please let me know if you have further questions.

5 ritachiu comentou às Link permanente

Thanks for the article.
I have enable the BPEL extensions but the Expiration Tab is missing in the Properties View of the invoke activity inside a microflow process. Do you know if it is by design or if I am missing anything in my setup?

6 ritachiu comentou às Link permanente

Hi, updating my previous comment. I have noticed that only in a long-running process that the Expiration Tab is available in the Properties View. Thanks.

7 Lalitha_Chandran comentou às Link permanente

Thank you for stopping by. You are correct in your observation, I believe expiration tab is not available for microflow.

You will find an indirect mention over here:

8 ritachiu comentou às Link permanente

Hi Lalitha,

I have a long-running process (processA) which invokes another process (processB). When a transaction timeout occurred in processB, the transaction in processA will retry. Is there a way to catch the transaction timeout in this case to avoid the retry without setting the BPEL timeout?
For example, I have tried setting the BPEL timout in the invoke and the processA is able to catch the timeout fault. However, if BPEL timeout is not set and I just let the transaction timeout to occur, I am not able to catch the transaction timeout (catch all block does not catch it either) in processA.
As a result, I would like to see if there is a way to catch the transaction timeout without setting the BPEL timeout.

9 anknown comentou às Link permanente

Hello, Lalitha_Chandran.
Interesting article, but all information in it can be gained through analyzing logs of process server after the first occurrence of the transaction timeout error. And we are living in world where we need solutions of the problems, not only statement of fact about its nature.
So, the question is: what is the best way to avoid problems due to transaction timeout error?
For example, we have a huge long-running process with one external call of web-service that is very load-sensitive. So, sometimes this web-service becomes “long-responding” and this leads to transaction timeout. BUT! Java thread still running and doesn’t know anything about that, so it puts in our database message “all complete successful”.
And then:
1) Then the transaction service of Application server begins retries of this activity what leads to even more loading external service thus the first process instance that done this activity for 181 seconds leads to other process instances to work on this activity longer.
2) Process instance fails on step BEFORE external call but our database says us that this step is already finished.
Of course, we could set transaction timeout time to infinity, but here we get a new question: what good we have from this mechanism (timeout)?
Could we programmatically catch “transaction timeout event” in our thread to stop writing “success” to our database?
Is it better to change application server configuration (set transaction timeout time) that applies to ALL applications on the server, or its better to remove this invoke from the process, let’s say, by adding wait+scheduler?
Is it a dangerous way to set “no transaction timeout” and once and forever forgot about this error?
I will appreciate your reply!

10 Bill Wentworth comentou às Link permanente

Hi Rita (ritachiu) and anknown.
Thank you for your comments. Unfortunately, these questions/problems go beyond the scope of his blog entry. You can open an SR / PMR (problem record) with the support center for assistance. Here is a link with information for the SR tool:

Thank you!
Bill Wentworth
Blog Moderator

11 Lalitha_Chandran comentou às Link permanente

Thank you Bill for pointing them to the SR tool. Would like to add my 2 cents.

Hello ritachiu-
Thank you for leaving a comment. The transaction timeout and/or the transaciton rollback exception will be thrown while checking the transaction boundary. So depending on your configurations the exception might or might not be caught. You can try setting the qualifier, "Join Transaction" to false on the target component and see if that helps. As Bill indicated please feel free to open a PMR.
The purpose of the article was to talk about the nature of the transaction timeout, since this behaviour is not very well known and we do get PMRs on such topics.
In my understanding, the best way to avoid problems around transaction timeout is to ensure that transactions complete in a timely fashion. If a transaction might take a long time, please ensure you have other timeout settings in place to catch it.
Setting “no transaction timeout” or setting transaction timeout time to infinity is definetly not suggested and is not going to solve the underlying problem. Generally speaking the very reason we have the transaction timeout setting in place, is to have an indicator that the transactions in the system are running long and holding up the resources. Example, a backend database has a problem and is taking a long time to respond.
In your scenario you can take the help of timeout settings within the web service, it will terminate the call. You cannot programtically catch a transaction timeout exception, because it is not an exception to begin with, its a information message. Instead you can check if the transaction has been marked for a rollback, since the transaction will be marked for a rollback once the transaction timeout has occurred.
I am not sure about the wait+scheduler method, but please feel free to open a PMR for it. Thank you for your comments/questions.

12 Raj Chaudhary comentou às Link permanente

Hi Lalitha,
I have a bpel process which uses wait activity in parallel path. Wait is set for 5 mins. When this bpel is deployed in UAT env., this wait activity sometimes keeps waiting (as seen in BPC) and that parallel path never finishes.

Any thoughts on why it does that.

13 Bill Wentworth comentou às Link permanente

The following response is being posted on behalf of Lalitha while she is out of the office.

Hello Raj-
Thank you for the question. Unfortunately, these questions/problems go beyond the scope of his blog entry. You can open an SR / PMR (problem record) with the support center for assistance. Here is a link with information for the SR tool: