Hi Dima,
Thanks for your time and explanations :-)
However, I have the intuition that it will take me more time to implement
your idea compare to the builtin feature of PostgreSQL.
Nevertheless, I keep your idea in mind in case of I have problems with
PostgreSQL.
Have a nice day.
--
Ludovic Gas
Hi Antoine & Chris,
Thanks a lot for the advisory lock, I didn't know this feature in
PostgreSQL.
Indeed, it seems to fit my problem.
The small latest problem I have is that we have string names for locks,
but advisory locks accept only integers.
Nevertheless, it isn't a problem, I will do a mapp
On Tue, 17 Apr 2018 13:34:47 +0200
Ludovic Gasc wrote:
> Hi Nickolai,
>
> Thanks for your suggestions, especially for the file system lock: We don't
> have often locks, but we must be sure it's locked.
>
> For 1) and 4) suggestions, in fact we have several systems to sync and also
> a PostgreSQL
Hi Nickolai,
Thanks for your suggestions, especially for the file system lock: We don't
have often locks, but we must be sure it's locked.
For 1) and 4) suggestions, in fact we have several systems to sync and also
a PostgreSQL transaction, the request must be treated by the same worker
from begi
Hi, redis lock has own limitations and depending on your use case it may or
may not be suitable [1]. If possible I would redefine problem and also
considered:
1) create worker per specific resource type to avoid locking
2) optimistic locking
3) File system lock like in twisted, but not sure about p
Hi Roberto,
Thanks for the pointer, it's exactly the type of feedbacks I'm looking for:
Ideas that are out-of-box of my confort zone.
However, in our use case, we are using gunicorn, that uses forks instead of
multiprocessing to my knowledge, I can't use multiprocessing without to
remove gunicorn.
