> Hi Folks,
> Newbie here, but I've been looking at the locking code for Vulcan
> and I have a question about some of the behavior I've seen.
> If I prepare and execute the following:
> SELECT * FROM FOO;
> I see a SharedRead lockstaken on FOO's rel_existence_lock. The lock is
> taken during the parsing phase:
> 1* In routine engine11:\lock_LockMgr_ss\LockMgr::LOCK_enq 826
> 2 Called from engine11:\jrd_lck_ss\enqueue 1160
> 3 Called from engine11:\jrd_lck_ss\LCK_lock 682
> 4 Called from engine11:\jrd_met_ss\MET_lookup_relation_id 5826
> 5 Called from engine11:\jrd_Attachment_ss\Attachment::findRelation
> 6 Called from engine11:\jrd_par_ss\par_relation 2008
> 7 Called from engine11:\jrd_par_ss\parse 2594
> However, even if I do a ROLLBACK; after the select, that lock is still
> retained. I know this because of setting a watch point on
> lock->lbl_counts and it happens both with isql and with our
> Question: Is this SR rel_existence_lock being retained on purpose as a
> possible optimization (ie, since you're already interested in the lock,
> just leave it until you need to give it up)?
This lock means that corresponding object is loaded into metadata cache
of some FB proccess. In case of classic architecture (shared mode in Vulcan)
there are more then one processes. In SAS's NO_SHARED mode each
connection have its own private metadata cache, IIRC
> If I then submit DROP TABLE FOO; (using a normal connection, ie the
> default lock wait) the SR lock gets converted to a Exclusive lock and
> the table gets dropped.
When process asquire exclusive lock all other processes holding shared
locks receive notification (AST sent by lock manager) and must remove object
from private metadata cache and release its locks (if it possible of course).
> However, if I submit the DROP TABLE when I've told the connection NOT to
> wait on locks, I see a "object in use" error.
Because another processes not released its shared locks
> When vulcan sees that the
> existing lock is not compatible, it fails the lock attempt without
> tyring to take the lock.
> Question: I believe that the aspect of not attempting to take the lock
> when nowait is in effect is the correct and intended behavior. Does
> anyone think that this is NOT correct?
Hmm... i have no enough expirience with vulcan in this area so
can comment right now, sorry.