Re: Packaging of a Web viewer of medical images
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
Reply to: