PS. The fix also allow to schedule a one time task to run on a specific worker which is useful in its own.
On Aug 11, 7:33 pm, Massimo Di Pierro <massimo.dipie...@gmail.com> wrote: > You found a major bug. I think it is not fixed in trunk (more or less > as you suggested). Please check it. > > The database locked issue should not raise, perhaps there is a sqlite > flag. > > Massimo > > On Aug 11, 6:33 pm, Niphlod <niph...@gmail.com> wrote: > > > > > > > > > Really totally insane rambling. > > Reference in task_run doesn't block worker two executing the > > function... > > > So, another rambling: > > In order to avoid it, at the cost of firing two queries on > > task_scheduled table, wouldn't be better to "sign" the task_scheduled > > with, say, worker_heartbeat.id and then check, after the first commit, > > if the same record is being taken up by another worker? > > > Something like: > > > 1. worker 1 fetches task_scheduled.id=1 and updates the record with > > worker_id=1 and status=running > > 2. commit() > > 3. worker 1 re-fetches task_scheduled.id=1 and checks if worker_id is > > still == 1 > > 4. task_run record is inserted > > 5. db.commit() > > > and so on... > > > would this kind of approach seal the deal or it's a "chicken and egg" > > problem and we'd need to separate delicate processes "intelligently" > > using task_scheduled.group_name and only a worker doing those ?
