Em Terça 16 Maio 2006 20:49, Robin Haswell escreveu:
> This is true, in fact I think the only slightly complicated bit would be
> maintaining concurrency between the scheduler in memory and the tasks in
> the table. You don't want to be querying a database every second
> (although that would work around a particular MySQLdb bug people have
> mentioned), however in a clustered environment you can assume that tasks
> will be added to a table by another process on occasion - a process
> which is unable to notify the server that is running scheduled tasks
> that the task list has changed (within reason).
What I thought would be persistence only:
- a new task is added to the database when scheduled
- the task is removed from the database when run
This is so because if there's some anomaly or crash when the application
restart it can read and reschedule all pending tasks from the database. It
doesn't need to read all the time from there.
In a multi-server environment all servers read from the database when
starting. If you need separate tasks, each server can have an individual
table or you can add a server-identification column to the persistence layer.
> On the other hand.. is querying a database every second so bad? I wonder
It is. Specially because this will probably use the same database that your
production system uses. And, if your systems are like mine, your web
application won't be the only one using such database.
There are really expensive products that are limited by simultanous
connections as well.
> how people would react to a "select list, of, fields from table where
> date <= now())" every second. A production application should be
> processing at least a page request a second, which is usually a lot more
> than one query. Our primary combi-webserver at work handles about 5
> requests for pages a second, almost all of them requiring more than one
> query, without breaking a sweat.
How does it scale if you insert other systems using the database to collect
information for reports, statistics, data modification, etc. Also think
datawarehouse...
> But if people are concerned perhaps we could get all the tasks for the
> next minute at once and store them in-memory?
Why not all pending requests and use the scheme I outlined above? It looks
more database friendly and the end result is the same.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
