On Wed, Feb 25, 2015 at 10:08:19PM +0100, Karsten Hilbert wrote: > OK, in that case you don't need the above manual table based locking ! > > Use an exclusive advisory lock: > > > http://www.postgresql.org/docs/9.4/static/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS > > like so: > > The client (Orthanc) needs a global (across threads) state, say, > "db_is_locked". > > ... Orthanc starts up ... > set db_is_locked to TRUE
This must be "set db_is_locked to FALSE", of course ! > ... connect ... > select pg_try_advisory_lock(999); # doesn't matter, > unique and constant > fails: > database in use by another Orthanc instance > abort > succeeds: > we've got the database locked for this instance of Orthanc > set db_is_locked to TRUE > > ... plugin is loaded and wants to connect ... > select pg_try_advisory_lock(999); > fails: > database is locked by us (see above) or another instance > check db_is_locked: > if FALSE: > something is wrong because we should have aborted > earlier _or_ else would have set db_is_locked to TRUE, > abort > if TRUE: > database is locked by us, > proceed to connect > [1] > succeeds: > something is wrong because we either already hold the > (exclusive) lock or another instance held the lock at > which point we would have aborted (see above) > abort > > Voila ! :-) > > > [1] Here one might use pg_try_advisory_lock(ORTHANCE_INSTANCE_UUID) > to make extra sure (paranoia) that it is _really_ us who locked > the database -- if this lock _fails_ we are good, if it succeeds > some other instance locked the DB (for debugging look at > pg_stat_activity...). -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150227162311.gb23...@hermes.hilbert.loc
