G
gus bjorklund
Guest
for self-serving 4GL sessions, when waiting for a lock, the session blocks on a semaphore. when the lock-holder releases the lock, it also signals the waiting session's semaphore to wake it up. the waiting session then tries to acquire the lock again. for client-server 4GL sessions over the network, when waiting for a lock, the 4GL session is waiting for a network message from the server. the network message normally contains the requested record. when there is a lock conflict, the server queues the lock request and marks the database connection as waiting. when the lock holder releases the lock, it marks the connection as server action pending and marks the server as one of your clients needs attention. when no longer serving an earlier request, the server sees this and tries to acquire the lock again. in PASOE, the worker thread can go do work on behalf of another session when the session is waiting for a lock. but i do not remember if it actually does this or if the worker thread blocks. there is another possibility though: the lock may not be released by the lock holder - it may be only have been downgraded from exclusive to share at the end of a transaction and there may not be any active transactions other than the blocked client's. in this case, if the client wants a share lock, it will be granted. but if the client wants an exclusive lock, it will have to continue waiting even though it is the only session with an active transaction.
Continue reading...
Continue reading...
