--
me at github: https://github.com/radiospiel
me at linked.in: https://www.linkedin.com/in/radiospiel
> You probably considered this but the queuing mechanism I use
> doesn't hold
> locks on records during processing. Workers claim tasks by locking
> them,
> setting a claimed flag of some sort, the releasing the lock (including
> worker identity if desired) - repeating the general procedure once
> completed.
>
> My volume is such that the bloat the extra update causes is not
> meaningful
> and is easily handled by (auto-)vacuum.
>
> David J.
Hi David,
well, I though about it and then put it to rest initially, since I liked
the idea that with a running job kept “inside” the transaction I
would never have zombie entries there: if somehow the network connection
gets lost for the client machines the database would just rollback the
transaction, the job would revert to its “ready-to-run” state, and
the next worker would pick it up.
However, I will probably reconsider this, because it has quite some
advantages; setting a “processing” state, let alone keeping a worker
identitiy next to the job seems much more straightforward.
So how do you solve the “zombie” situation?
Best,
Enrico
