Transaction timeouts....bug?

[modjoe23]

I have a message driven bean which is processing a transaction which cam sometimes run for hours. The main goal I am trying to acheive is to increase the transaction timeout from the default 300 seconds (5 mins) to somehere in hours. The code below demonstrates the number of things I have tried to acheive this, but I have been unsuccessful in every attempt. I am starting to think there may be a bug in one of the transaction annotations. Please help...thanks!

- 1. Tried setting the context from setMessageDrivenContext which is called by the container. I then got the user transaction and tried to set that timeout to > 5 mins but that did not affect the 5 min default trans. timeout. (Please see commented code)

- 2. Tried setting the @TransactionTimeout annotation to a value > 500 but that seems to do nothing...bug?

- 3. Any other suggestions?

@TransactionManagement(TransactionManagementType.BEAN)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
@TransactionTimeout(value=800)
public class MDBDataLoadTask implements MessageListener,MessageDrivenBean {
private MessageDrivenContext ctx;

public void onMessage(Message msg)
{
/*
UserTransaction aUT = ctx.getUserTransaction();
aUT.begin();
aUT.setTransactionTimeout(360);
*/

try
{
//Perform a task that will take about this long to run
Thread.sleep(365000);
//aUT.commit();
}
catch (Exception e)
{
/*try{
aUT.setRollbackOnly();}
catch(SystemException se){System.out.println(se.toString());}*/
}
}

@Resource
public void setMessageDrivenContext(MessageDrivenContext ctx) { this.ctx = ctx; }

public void ejbRemove() {ctx=null;}
}

[modjoe23]

I know that I can change the default timeout value from the default 300 seconds in jta-service.xml but I am looking to change the transaction timeout for this transaction only. I've also read the spec but with no luck.

Anybody out there?? Please help!

[marklittle]

Depends what API you're using, but both JTA and OTS have a setTransactionTimeout (or set_timeout) method that operates on the current thread and transactions it creates from that point on. Check the JBossTS manuals (or the JTA/OTS specifications) for more details.

[modjoe23]

Thanks.

So I take it there is no way to do it using annotations?

[stone_42]

Depends what API you're using, but both JTA and OTS have a setTransactionTimeout (or set_timeout) method that operates on the current thread and transactions it creates from that point on. Check the JBossTS manuals (or the JTA/OTS specifications) for more details.

In http://wiki.jboss.org/wiki/Wiki.jsp?page=TransactionTimeout there is a good description how to do it.
The page also says that the timeout I set will apply to all transactions started after the setting on the same thread.
Now, the ejbs in my application are called from a Web Application and as we know, Tomcat uses thread pools, so the thread on which I set the transaction timeout will be reused very often and in contexts I do not know and probably I don't want to have the special timeout set for one method executed anywhere in the history of the thread.
So I wonder if there is a possibility to reset the transaction timeout on the executing thread to the default value, as I don't want to set the value every time I start a new transaction anywhere in my code.
I tried to find out looking at the code of JBossTS4.2.3sp5 and found that the transaction timeout is stored in a hashtable (com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction._timeouts) with the thread's id as key and never is removed from that hashtable.
Did I miss where the transaction timeout is reset or is it just not reset anywhere?

[adinn]

You are right that the hashtable does not get cleared. However, setting the value to 0 does ensure that the default timeout is used next time round i.e.*logically* it clears the table.

The simplest solution to your problem is to do the work yourself but *only in the long-running method*. Save the existing timeout at transaction begin then reset to your desired value. At commit restore the original value -- if you know it will always be 0 then there is no need to save at begin, just reset to 0. n.b. if the code following the begin might raise an exception then ensure the reset happens by using a try finally.

[marklittle]

Yes, as Andrew points out, a timeout of 0 is the same as not setting a timeout. It does not mean that there is no timeout associated with the transaction, only that it is implementation dependant. I believe (from memory) the text we used when writing the standards was something like "no application specific timeout is set".

[obfuscator]

I just got the transaction timeout on an MDB to work, by using BMT and ut.setTransactionTimeout(...).

Using CMT, it doesn't seem like @TransactionTimeout works, nor using TransactionAttribute.NEVER or NOT_SUPPORTED, I still get timeouts. Is this expected behaviour? Are transactions already started when control enters onMessage? Is this why it doesn't work? I tried to set @TransactionTimeout on both the bean class itself and on "onMessage". I'm still puzzled as to why NEVER and NOT_SUPPORTED doesn't work.

While performing the tests, I used 4.2.2-GA, and used StrictMaxPool with one instance and timeout set to Long.MAX_VALUE.

Thanks

[adinn]

Using CMT, it doesn't seem like @TransactionTimeout works, nor using TransactionAttribute.NEVER or NOT_SUPPORTED, I still get timeouts. Is this expected behaviour? Are transactions already started when control enters onMessage? Is this why it doesn't work? I tried to set @TransactionTimeout on both the bean class itself and on "onMessage". I'm still puzzled as to why NEVER and NOT_SUPPORTED doesn't work.

As Mark confirmed in a previous note: when a transaction client fails to set a tmeout or sets a zero timeout then an implementation-specific interpretation is adopted, In the case of the JBoss JTA this means the timeout property configured form the JBoss transaction properties (600 seconds unless you reset it) is used as the timeout value.

You might like to take this to the EJB forum and ask them why they don't set a timeout value of Integer.MAX_VALUE when a bean specifies NEVER or NOT_SUPPORTED. You had probably better consult a language lawyer first :-)

(n.b. the limit has to be from Integer rather than Long because the timeout supplied in seconds has to be convertible to a timeout in machine time units -- it's still long enough to mean NEVER for all practical purposes)