javamongodbmongock

What are consequences of deactivating the Mongock-Lock?


Mongock documents that the "default, expected and documented behaviour" for database migrations is to acquire a pessimistic lock on the whole database.

It is, however, possible to run a migration without this lock. This functionality is available without hacks by using the @NonLockGuarded-annotation on a repository-bean used in a migration (which has been suggested as a workaround for another problem, see this thread).

What are the potential dangers of deactivating the lock, and what rules do I need to obey to do this safely?


Solution

  • Important note: Don't confuse using @NonLockGuarded with not using the lock at all. The lock will be still used, however, the annotation @NonLockGuarded deactivate one of the techniques Mongock uses. It actually the less important one.

    Short answer: Although very unlikely, the consequences are a potential race condition between two instances that are being deployed simultaneously. But as said, it's very unlikely and I would very confident in using the annotation @NonLockGuarded

    Long answer: Although Mongock acquires the lock before starting the process and has a daemon to extend the lock in the background, if the process exceeds the lock's acquisition time, Mongock has an extra layer to synchronise multiple Mongock's runners(multiple instances competing to execute the Mongock process), in which it ensures the lock is acquired with a safe margin before executing every single synchronised operation(database operation or any other operation that needs to be synchronised between runners). It uses Java proxies for this.

    With the @NonLockGuarded annotation on a class, parameter, etc., this check is not executed and it could lead to a race condition in case the daemon, for any reason, is not able to extend the lock correctly.

    However, this is an extra layer that Mongock adds(no other vendor does) to reduce to the very minimum the chances of a race condition. But as said, even without this, it's very unlikely it happens and I would be confident to run a Mongock process without it in case you need to disable via @NonLockGuarded.

    Note: In next released we are going to add a configuration parameter to disable the proxy(what @NonLockGuarded does) to the entire process.