[Async-sig] asyncio.Lock equivalent for multiple processes

[Nathaniel Smith]

Pretty sure you want to add a try/finally around that yield, so you release
the lock on errors.

On Tue, Apr 17, 2018, 14:39 Ludovic Gasc <gmludo at gmail.com> wrote:

> 2018-04-17 15:16 GMT+02:00 Antoine Pitrou <solipsis at pitrou.net>:
>
>>
>>
>> You could simply use something like the first 64 bits of
>> sha1("myapp:<lock name>")
>>
>
> I have followed your idea, except I used hashtext directly, it's an
> internal postgresql function that generates an integer directly.
>
> For now, it seems to work pretty well but I didn't yet finished all tests.
> The final result is literally 3 lines of Python inside an async
> contextmanager, I like this solution ;-) :
>
> @asynccontextmanager
> async def lock(env, category='global', name='global'):
>     # Alternative lock id with 'mytable'::regclass::integer OID
>     await env['aiopg']['cursor'].execute("SELECT pg_advisory_lock(
> hashtext(%(lock_name)s) );", {'lock_name': '%s.%s' % (category, name)})
>
>     yield None
>
>     await env['aiopg']['cursor'].execute("SELECT pg_advisory_unlock(
> hashtext(%(lock_name)s) );", {'lock_name': '%s.%s' % (category, name)})
>
>
>
>>
>> Regards
>>
>> Antoine.
>>
>>
>> On Tue, 17 Apr 2018 15:04:37 +0200
>> Ludovic Gasc <gmludo at gmail.com> wrote:
>> > 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 mapping between names and
>> > integers.
>> >
>> > Yours.
>> >
>> > --
>> > Ludovic Gasc (GMLudo)
>> >
>> > 2018-04-17 13:41 GMT+02:00 Antoine Pitrou <solipsis at pitrou.net>:
>> >
>> > > On Tue, 17 Apr 2018 13:34:47 +0200
>> > > Ludovic Gasc <gmludo at gmail.com> 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 transaction, the request must be treated by the same
>> worker
>> > > > from beginning to end and the other systems aren't idempotent at
>> all,
>> > > it's
>> > > > "old-school" proprietary systems, good luck to change that ;-)
>> > >
>> > > If you already have a PostgreSQL connection, can't you use a
>> PostgreSQL
>> > > lock?  e.g. an "advisory lock" as described in
>> > > https://www.postgresql.org/docs/9.1/static/explicit-locking.html
>> > >
>> > > Regards
>> > >
>> > > Antoine.
>> > >
>> > >
>> > >
>> >
>>
>>
>>
>> _______________________________________________
>> Async-sig mailing list
>> Async-sig at python.org
>> https://mail.python.org/mailman/listinfo/async-sig
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20180417/c116dcd5/attachment-0001.html>