Keiran,
I do something very similar to this except I typically use an
external scheduler such as cron or launchd, which calls direct
actions using curl to handle each task. This way the scheduling
databases becomes a simple crontab or launchd style schedule.
There are many options to this, but I do agree that the scheduling is
best done outside your application. Things get much simpler that
way, especially where multiple instances are involved. Otherwise you
have issues with ensuring the timer is running in only a single
instance of your application and other related issues.
On May 9, 2007, at 9:35 AM, Kieran Kelleher wrote:
I'll try and be brief ......... For stuff like this I create
scheduled tasks in the database. ScheduledTasks have a start date
(1/1/2007 0:00 for example) and end date(12/31/2008 10:00 for
example) and a frequency (1, 2 ... n) and an interval (minutes,
hours, days, weeks, months) and a class name that implements
ScheduledTask interface. Related to that are many
ScheduledTaskEvents, one for each time the task has executed. Since
I run multiple instances, I have a standalone app
(ScheduleManager.woa for example) that regularly (every 60 seconds
for example) checks the schedule table for tasks to be executed,
creates new ScheduledTaskEvents in the db for tasks that are to be
executed, and then issues a direct action to the multiple instance
app with the ScheduledTaskEvent ID. The task is executed and that's
it. The ScheduledTaskEvent entity has STATE such as INIT,
PROCESSING and DONE. The ScheduledTaskManager only sends DA's for
ones with INIT state.
That's the strategy anyway... it has worked solid for a very long
time.
If you try and go the simple route with a simple java Timer, then
AFAIK you will lose that task if you restart your app before it
gets executed. So, if you want persistence and reliability, I think
you have to consider a way to persist your scheduled tasks in the
database and have "Singleton" style app in your cluster that
triggers the scheduled task events. The to-many tasks events allows
me to ensure that every task is absolutely executed which is
critical since many of the tasks are related to automatic
subscription payments and credit card charges.
HTH, Kieran
On May 9, 2007, at 5:47 AM, Johann Werner wrote:
I recently looked at the NSTimer documentation where a note came
up stating that it is obsolete and should not be used for new
development. Unfortunately there is no mention of alternatives.
I have a WO app running that should execute a function at certain
dates automagically ;) More precisely: people can register for an
event and put in different information. At a certain date (to make
sense a couple of days ahead of the event) the app should check if
all mandatory information has been entered and sends a reminder
email to that person if not.
By searching the web the only way if found to implement such
behaviour is using a cronjob with wget and a direct action. But by
this the app loses control of when the action gets called as it is
hardcoded. Additionally I would have to add this call manually in
a system config file. I think that's no good as it is not directly
related to the app and therefore adds to the install/maintenance
complexitiy.
What is the common practice to implement such timing needs?
jw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/robertwalker1%
40mac.com
This email sent to [EMAIL PROTECTED]
--
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
