On Wed, Feb 25, 2015 at 05:12:08PM +0100, Sébastien Jodogne wrote:
> The locking of the database is just a feature to prevent two distinct
> instances of Orthanc from using the same database. Nothing prevents 2
> instances of Orthanc from using the same PostgreSQL database, but this might
> result in surprising behaviors if the configurations of these instances are
> inconsistent (think for instance about the "MaximumStorageSize" option [1]).
>
> Technically, "Locking" only means that a value is set in a table to say that
> some instance of Orthanc is using the DB. Similarly, "unlocking" means
> removing this value. In other word, this is not a locking at the PostgreSQL
> level.
>
> If you are certain that a single instance of Orthanc will use the DB at any
> time, you can use set the "Lock" option to "false" in the configuration file
> to disable this locking mechanism.
>
>
> > May I ask whether Orthanc uses a persistent connection to
> > PostgreSQL or temporary ones ? In case it uses a persistent
> > connection I am pretty sure we can come up with a scheme
> > which does NOT require a manual unlock should Orthanc shut
> > down out-of-order.
>
> Each of the plugins creates 1 single PostgreSQL connection
>
> that is opened at the initialization of the plugin (during the startup of
> Orthanc), and that is closed at the finalization of the plugin (during the
> finalization of Orthanc).
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
... 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
earler _or_ 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...).
Karsten
--
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/20150225210819.ga2...@hermes.hilbert.loc
