Hello, Jim,

>>
>>Could kindly gurus answer my dummy question ? The question is:
>>What lock manager operations are safe to perform at AST level ?
>>
>>
>>
>>
> Generally speaking, only downgrades and releases. Requesting a lock at
> AST level could
> kick off another AST which might deadlock the lock manager. Since the
> architecture only
> requires downgrades and releases, it is likely that nothing else has
> been tried, let along
> exhaustively tested.

I already understood this. I based my NBACKUP (redirection of writes
to difference file) work on Open Sourced IBM DLM documentation (derived
from VMS lock manager). This stuff is fully signal-safe and supports
asynchronous locking. Now I'm reworking my code because I understood
that it is impossible to get lock on the resource from signal handler
with Firebird internal lock manager even if there are no ASTs involved
and deadlocks are not possible. Simply because Firebird lock manger
can have only one blocked lock request per owner by design.

>Why are you trying to do?

This lack of functionality forces me to somewhat less-efficient
implmenentation. I wanted to give out backup lock instantly, without
flushing of node caches, but this would require some synchronization
in the write_page code possibly executed from AST handler. I'm forced
to flush all dirty buffers in all caches before giving out database
backup lock (happily enough I can do this without monopolizing the engine,
as writes are already redirected at this point).

All this happens because I want to keep compatibilty between standard
classic operation and mode of operation using Distributed Lock Manager.
Otherwise I could use some custom shared memory structure for
synchronization.


--
Nickolay Samofatov