Dmitry Yemanov wrote:

> All,
>
> In Vulcan, we may have a few engine providers within a single
> installation. It's supposed that every of them is responsible for each
> own ODS. The problem is that each engine provider may have different
> (read: incompatible) lock manager implementation. As all providers by
> default share the same root directory (and hence the lock table), an
> attempt to use them simultaneously would cause server crashes and
> database corruptions. Am I missing something or is it a real problem? If
> the latter, how are we going to guarantee the consistency? Also, even if
> all engines are configured for different roots, this issue implies that
> one would need a few versions of fb_lock_print in order to analyze the
> lock table.
>
> Comments?
>
>
>

If I remember correctly, the name of the lock file can be specified in
the configuration for each engine provider, which should handle the
problem quite nicely.

In fact, you might turn your gaze to the method LockMgr::init_lock_table
in LockMgr.cpp, you will find the strategic line:

JString lockFileName = configuration->getValue (LockFileName,
LockFileNameValue);

If you look around, you will also see

LOCK_shm_size = configuration->getValue (LockMemSize,
LockMemSizeValue); //Config::getLockMemSize();
LOCK_sem_count = configuration->getValue (LockSemCount,
LockSemCountValue); //Config::getLockSemCount();
LOCK_hash_slots = configuration->getValue (LockHashSlots,
LockHashSlotsValue); //Config::getLockHashSlots();
LOCK_scan_interval = configuration->getValue (DeadlockTimeout,
DeadlockTimeoutValue); //Config::getDeadlockTimeout();

A reasonably prudent thing to do is to establish some conventions for
lock table names so distros can go out with mutually compatible
configurations.