Thanks for the suggestion the transaction appears to be the key. I had separated the code and called another ejb that would perform the DB transaction. Now that I am requiring a new transaction it seems to be allowing the timer code to run as I wanted.
Thanks for the help.
---
Dru Devore
The best Christian community now online.
The Faith Haven
www.thefaithhaven.com
Come join us, bookmark us, and enjoy!
-------- Original Message --------
Subject: Re: RE: Keeping a timer alive
From: glassfish@javadesktop.org
Date: Fri, July 25, 2008 5:05 pm
To: users@glassfish.dev.java.net
One problem is that if you get an exception within Toplink, it completely grenades your transaction, and you're doomed forever.
The way I handled this was I had the Timer code call another Session Bean with "REQUIRES_NEW" for the transaction attribute, this separated the actual running code from the Timer code, which leverages the current transaction (far as I can tell). With the business logic in a completely different transaction, it can whine and complain and implode for whatever reasons it wants, while keeping the Timer transaction "clean". This is the easiest way to insulate a Timer process from the vagaries of what's running inside of it.
I also, as a rule, have timers reschedule themselves so that if the process for some unknown reason "takes too long", you don't have to worry about the same process running on top of itself.
YMMV. Do not use while bathing. No user serviceable parts inside.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=289470
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net