along with a flag indicating whether the timer is persistent and thus should survive server
When scheduling using the TimerService , the bean invoking the schedule methods
must have a time-out method. When using the TimerService , you're specifying an
alarm for the current bean into which the TimerService was injected—you can't speci-
fy another bean. The bean must either have a method annotated with @TimeOut or imple-
ment the TimedObject interface. This will be demonstrated in the ad hoc timer example.
The TimerService participates in transactions. When a new timer is created within the
context of a transaction, the timer is cancelled if the transaction is rolled back. The time-
out method can be executed within the context of a transaction. If the transaction fails, the
container will make sure the changes made by the failed method don't take effect and will
retry the time-out method. Now that you have a basic handle on ad hoc timers, let's take a
look at an example from ActionBazaar.
7.3.2. Programmatic timer example
Marketing frequently has the need to send out flyers advertising items for sale on Ac-
tionBazaar and enticing potential bidders and sellers to check out the site. Timing is critical
for the flyer. Send it out toward the end of the workday and people will probably forget
about the notice by the time they get home. Send it out before a long holiday weekend and
it'll stay buried in people's inboxes. As a result, when the flyer is approved and ready to
be sent isn't necessarily the time that it should be sent. When uploading a flyer for distri-
bution, ActionBazaar prompts for the date and time the email blast should be sent. This is
similar to the previous newsletter example except that it's an ad hoc email blast not done
with any regularity. The scheduling information specified by the marketing person is pack-
aged up into a ScheduleExpression , and the scheduleFlyer on the FlyerBean
is invoked. The code for this bean is shown in the following listing.