Transaction Timeouts

[Kiran Gunda]

I am using CMT, and I set the transaction timeout (say 20secs). From my EJB, I am calling some external system's APIs. These APIs sometimes take more than 20 secs.. Generally containers throw the TimeoutException only after the thread completes its processing (that means Client has to wait longer than the transaction timeout..).

Is there any pattern (programming practise) that will allow the Bean provider to throw the TimeoutException as soon as it elapses the transaction timeout (in this case, in any circumstances client should not wait more than 20 secs)..

Thanks,Kiran

[Thomas Taeger]

Hello Kiran Gunda,
I feel not very firm in your area, but it sounded interesting. So first I have some questions:

Originally posted by Kiran Gunda:
Generally containers throw the TimeoutException only after the thread completes ...

Which thread? When designing for EJBs I do not think in threads. All J2EE for reliability reasons avoids any multi-threading in business-processing, so server-side I am thinking of a good old one-thread system, and this server thread never completes as long as the EJB container is up and running, right?

Or did you mean an EJB connection completes? Or a stateful session?

Originally posted by Kiran Gunda:
I set the transaction timeout (say 20secs).

From database programming we know that transactions should last as short as possible.
An EJB CMT transaction lasts from the arrival of a clients call at the EJB container until its return, including the time for all server-side work and also for calls to external systems, right?

For an external system participating in transactions I guess both the EJB container and the external system should delegate transaction monitoring to one common transaction monitor, presumed the external system is able to:

a) Then the EJB provider should not need to take care of the duration of the external call. The transaction monitor would do that for both, right?

b) Else the externaly spent time is just subsumed in the total EJB connection time, right?
I do not understand why this should not be able to raise a timeout event as I read in "Generally containers throw the TimeoutException only after the thread completes its processing".
b1) If the EJB container supports transaction timeouts then I would expect a rollback occuring.
b2) If the EJB container does not support transaction timeouts then just calling a programmatic timeout method could make sense. For this intention since EJB 2.1 you could start a lightweight count-down timer thread by getTimerService().createTimer() and
b2a) before ending (i.e. on timeout) this little thread would tell the EJB container to rollback the transaction.
b2b) Otherwise if the external call returns fast enough you stop the count-down timer.

Maybe this gives some new ideas ...

Thomas
[ June 16, 2006: Message edited by: Thomas Taeger ]

[Kiran Gunda]

Thomas,

Please refer this URL, it is better explained the issue that I was referring to :

http://support.bea.com/application_content/product_portlets/support_patterns/wls/Investigating_Transaction_Problems_Pattern.html#Transaction_Timeout_and_Transaction

Response to your Questions:-

(1) What I mean by thread was, When the EJB client invokes a method on EJB remote stub, then the EJB container allocates some thread to service this request. Now this thread is involved in executing your business logic, the EJB Container/Transaction Monitor does NOT stop this thread when the Timeout period is reached, instead it waits till the thread completes its processing, and then it checks whether it took more than the Timeout period or not. If it took more than the Timeout period then it throws TimeoutException to the client.

So client does NOT get the 'TimeOutException' as soon as the Timeout period is elapsed. If the thread is stuck due to some problem in your business logic, then client will never get any response.

(I did not mean that developer/bean provider creates the threads, rather they get created by EJB container)

I think some of your questions are answered.

I do have some logic in my mind:

(a) create a small thread program, which makes the remote method call on the session bean. So I call this thread program instead of calling the session bean directly. The thread comes out once the time out is expired.. This way my program doesn't stuck if the remote method call doesn't turn back in time..

But I am not sure whether this right approach or not

[Thomas Taeger]

Hello Kiran Gunda,
thanks for clarifying and providing the link.

Originally posted by Kiran Gunda:
So client does NOT get the 'TimeOutException' as soon as the Timeout period is elapsed. If the thread is stuck due to some problem in your business logic,

It is hard to believe, but I have read it too in the BEA link that you provided. Is that normal or a BEA bug? For me this implementation is not a timeout handling. And what is a transaction monitor good for if it is ignored?

Originally posted by Kiran Gunda:
(a) create a small thread program, which makes the remote method call on the session bean. So I call this thread program instead of calling the session bean directly. The thread comes out once the time out is expired.. This way my program doesn't stuck if the remote method call doesn't turn back in time..

At the client side this would surely fix the problem.
At the server side however more and more daemons could be running forever.
A server-side work-around that also kills the server-side processing/looping ... would be better, but there might not be a chance for a 2.1 timer-thread to stop the EJB main thread.
Therefore I would consider
- the timer-thread setting a time-out flag and
- to implement check-points in server-side loops within the main thread that check that time-out flag and - if set - throw an exception and return.
Harder to implement might be time-out detection on non-looping waiting for input, for resources, etc.

Thomas

[Kiran Gunda]

Thanks for your inputs. I am not sure whether we can call it as a bug, I would see it as a limitation. But I am trying to understand (exploring some BEA documentation) on why the container/tx monitor is unable to (or do not want to) interrupt the process when its taking more than the tx time-out limit.

And I agree with you, there is no clean way of handling this.

Timer is another option, but I remember I had faced some issues with Timers in clustered environment..( don't remember well, something like..Timers need to be started in each cluster separately..etc)...

I am not sure if other containers (Websphere..) has the same limitation on transaction timeouts..

Kiran

[Thomas Taeger]

Originally posted by Kiran Gunda:
... Timers need to be started in each cluster separately..etc)...

Explicitely starting the count-down timer (watch-dog) is needed anyway, because it has to be done at the beginning of the business method within the one actually handling container and can not be antipicipated by a [optionally clustered] container.
Maybe there are other reasons, but this in particular is not a barrier.

Thomas

[Ajith Kallambella]

This topic appears to be broader than just preparing for SCEA. I'm moving this over to EJB/J2EE forum for the benefit of a larger audience.

[Jaikiran Pai]

I am not sure if other containers (Websphere..) has the same limitation on transaction timeouts..

Its the same even in case of JBoss. And here are some related threads discussing a similar issue:

https://coderanch.com/t/317784/EJB-JEE/java/Identifying-Transaction-timeout


https://coderanch.com/t/303663/JDBC/java/Identifying-Database-Locked-scenario

[Jaikiran Pai]

Also, i am not sure whether this can be termed as a bug, since i could not find any documentation stating how transaction timeouts are supposed to be handled by app servers