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 <gml...@gmail.com> wrote: > 2018-04-17 15:16 GMT+02:00 Antoine Pitrou <solip...@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 <gml...@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 <solip...@pitrou.net>: >> > >> > > On Tue, 17 Apr 2018 13:34:47 +0200 >> > > Ludovic Gasc <gml...@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@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@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@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/