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