[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


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
		database in use by another Orthanc instance
		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);
		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,
		if TRUE:
			database is locked by us,
			proceed to connect
		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)

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

GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Reply to: