Timeout problems with an MDB performing long-running tasks

wesk...@optonline.net

unread,

May 6, 2008, 2:40:19 PM5/6/08

to

I have a JMS application running on Websphere 6. The application has an MDB which is performing a task which can currently take up to 5 minutes (in extreme cases) to complete before attempting to return a reply, by putting a message on a reply queue. I am testing this MDB using Websphere's SIB and Default messaging. In cases where I generate the reply in less than 2 minutes, everything is working fine. However, when the task takes longer I will then see the following in my log file...

TimeoutManage I WTRN0006W: Transaction XXXX has timed out after 120 seconds.

When the task finally completes and attempts to put the reply message on the reply queue, I will then see the following types of messages in my log...

XATransaction E J2CA0026E: Method addSync caught javax.transaction.RollbackException: Transaction rolled back

.

while trying to register the Resource Adapter with the Synchronization Manager for the current transaction, and threw a ResourceException.

SystemErr R javax.jms.JMSException: CWSIA0005E: The JCA runtime failed to allocate a connection.

.

Caused by: javax.resource.ResourceException: addSync: caught Exception

.

Caused by: javax.transaction.RollbackException: Transaction rolled back

This then seems to immediately resend the original message on the request queue as another instance of my MDB is triggered.

So I'm wondering

1) How do I control the length of time before a transaction times out?

2) Are there other ways to avoid the errors that occur when I am connecting to the reply queue?

3) How do I control whether or not a message is resent on the request queue when an error is encountered?

Thanks in advance.

Randy Schnier

unread,

May 6, 2008, 4:16:13 PM5/6/08

to

For controlling the length of the transaction timeout, you have two options: to do it at the server level, or to do it at the component (MDB) level.

To set the timeout for the entire app server, see http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ejbfep.multiplatform.doc/info/ae/ae/tjta_settlog.html

To set the timeout on an individual EJB, see http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.etools.j2ee.ui.ws.ext.doc/topics/tedglobtx.html

Hope this helps.

wesk...@optonline.net wrote:

[snip]

David Currie

unread,

May 13, 2008, 2:28:21 AM5/13/08

to

I guess the obvious question is whether, given you don't want the
message to be redelivered in the event of a failure, you actually want
to be using a transaction in the first place?

Regards,
David

wesk...@optonline.net

unread,

May 13, 2008, 2:17:11 PM5/13/08

to

David,

You make a very good point. The requests made to my application are to generate a (sometimes large) PDF document. So they are not truly transactional in nature. Is there a way to configure an MDB in a non-transactional way? Ideally I'd still have a timeout parameter somewhere, which would allow me to reply with a "request failed" message. I'm also open to other suggestions.

Thanks,

-Bill

Randy Schnier

unread,

May 13, 2008, 5:15:26 PM5/13/08

to

There are only two values allowed for method-level transaction attributes on an MDB: Required and NotSupported. Specifying NotSupported will cause the container to suspend any global Tx in effect at the start of the method, and resume it after completion of the method. A method-scoped "local" transaction will be in effect during the MDB's method. While technically not "not-transactional", a local transaction basically ensures that you close resources, such as connections, prior to completion of the method. In other words it mainly takes care of hygiene issues for you and does not have the overhead of a full global transaction.

wesk...@optonline.net wrote:
> David,

>
>
>
> Is there a way to configure an MDB in a non-transactional way?
>
>
>

> Thanks,
>
> -Bill

Paul Ilechko

unread,

May 13, 2008, 6:12:13 PM5/13/08

to

Perhaps you could have the MDB kick off an Asynch Bean to do the work?

David Currie

unread,

May 15, 2008, 4:50:07 AM5/15/08

to

The behaviour is slightly different for an MDB... There is no existing
transaction before invoking onMessage so NotSupported really means "no
transaction". Also, the message driving the MDB is received as part of
the onMessage methods transactional scope. So, if you set the
transaction attribute to NotSupported then the message is received
non-transactionally.

Regards,
David