Replies: 1 comment
|
To answer my second question it seems the scheduling is always UTC indeed, and there's this open issue #131 to add support for scheduling in a specific TZ. For the first point I am just not confident in this library always running correctly in a high-load, multiple-nodes configuration. It looks nice for single node schedulers, though. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi!
I've somehow stumbled upon this library and it peaked my interest as it's something that could be useful in my projects.
I gave a quick look at the implementation and I have a few questions if you don't mind.
(1) How is concurrency-control performed in a distributed scenario?
In the model there doesn't seem to be fields dedicated to optimistic concurrency, so what happens if two machines read and then update the same row at the same time?
The most efficient way to perform some concurrency control is certainly to use native DB locking, but that's pretty hard to do without relying on provider-specific commands.
(2) I see a lot of
DateTimetypes in the model. Am I correct to assume that these are all UTC?When I write a CRON is it UTC or local time or can I choose the TZ?
Is this library reliable during DST changes? It would be nice to see more tests in that area.
All reactions