set TransactionTimeout during Runtime

[bolbit]

Hello,

i have a Session Bean with CMT. In this bean, there is a method which reads out a database generates messages an sends them to a webservice.

Sometimes there are many messages to send, so that the execution of the methode exceeds the timeout so that the transaction is aborted by the transaction manager.

my vision is that i determine the number of messages and multiply it with x seconds (avarage sending time for 1 message) and have my transaction timeout.

But How can i set the timeout dynamically during runtime?
I found the following wiki-entry:
http://www.jboss.org/community/docs/DOC-12439

This document describes how to set the timeout via the UserTransaction BUT only for Transactions started AFTER the setting of the new timeout.

How can i do this with my CMT Bean?
When i commit the UserTransaction and start a new one within the method i recieve an exception

java.lang.IllegalStateException: Wrong transaction association

Can anyone help me with this problem?

Thanks in advance

[mclu]

Have you solved it?

I have a similar issue but I don't want to increase the timeout for the 97% mainstream handling like you....

Greets

[bolbit]

Hey mclu,

sorry, but I have no solution. I raised the Transaction Timeout for the EJB Method sending the messages and
accept that sometimes the method will be aborted because of a timeout. In order to avoid the rollback of the successfuly sended messages I use an EJB Method to send one single message with the transaction attribute "requieresNew". This Method is called from the method wich sends all messages.

So the abort of the outer method will have no effect on the messges already sent.

[sams]

Have you considered breaking up your EJB into two EJBs joined via a JMS queue? Basically have the first EJB generate the messages for the web service, and as it generates say 100 web service requests, it tosses those requests onto a queue instead of making those requests itself. Then have another EJB (MDB) consuming off of that queue and this EJB can have its own custom timeout based on when it should timeout on 100 web service requests.

This lets your first EJB reduce its work load to beat the timeout, and then the other EJB that is doing the web service requests will have its own timeout. Not only that, but since there is the second EJB doing the web requests, you can allow it do run those in parallel and get all your work done much faster and have it broken up with reasonable transaction timeouts.