Re: Scheduling Events?
От | Matthew Nuzum |
---|---|
Тема | Re: Scheduling Events? |
Дата | |
Msg-id | 008f01c2c574$6a0a66e0$6700a8c0@mattspc обсуждение исходный текст |
Ответ на | Re: Scheduling Events? ("David Durst" <ddurst@larubber.com>) |
Список | pgsql-sql |
> > Yes! cron > > > Here is the basic problem w/ using CRON in an accounting situation. > > I can't be sure that cron will always be up when the DB is up, > so lets say crond goes down for some random reason (User, System error, > Etc..) > > And outside adjustment is made to lets say the equipment account and that > adjustment was made on the value of the equipment, BUT it hadn't been > depreciated because crond went down and no one notice. > > Now I have a HUGE issue! > > So I have to be sure that all entries/adjustments are made accurately in > the time frame they were meant to happen in. > It seems that you have a good concern, so I have a suggestion. First, let me say that if you cannot count on cron to run your stuff at a certain time, then you cannot count on anything to run your stuff at a certain time. All of your reasoning for distrusting cron is perfectly valid in distrusting every conceivable automated system. Therefore, you have to design your application with the assumption that your scheduling system is untrustworthy. If you do that, then you have the freedom to use cron (or some other scheduling system) and build checks into your database activities to ensure that invalid data cannot be used if your scheduled processes did not take place. If you don't want to make changes to existing code, then you can create a solution as simple as a rule on your essential table(s) that first checks to make sure the most recent scheduled task was completed successfully and if it hasn't completed return something that the client will understand as invalid. If you're unfamiliar with "rules", they essentially rewrite your query on the fly. To quote Bruce Momjian's book, PostgreSQL: Introduction and Concepts, "Rules allow actions to take place when a table is accessed. In this way, they can modify the effects of SELECT, INSERT, UPDATE, and DELETE." I'm sure that you can think of several acceptable solutions if you learn to distrust your data. -- Matthew Nuzum www.bearfruit.org cobalt@bearfruit.org
В списке pgsql-sql по дате отправления: