This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Transaction Timeouts

 
Kiran Gunda
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 10444
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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


http://www.coderanch.com/t/303663/JDBC/java/Identifying-Database-Locked-scenario
 
Jaikiran Pai
Marshal
Pie
Posts: 10444
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic