8
0
mirror of https://github.com/FirebirdSQL/firebird.git synced 2025-01-22 22:43:03 +01:00

Fixed the status vector being left dirty after the non-critical lock manager error.

This resolves CORE-4265: Unexpected lock conflict error may be raised while connecting to a heavily loaded database.
This commit is contained in:
dimitr 2013-11-12 16:52:32 +00:00
parent 5356088542
commit 13949c0550
2 changed files with 13 additions and 1 deletions

View File

@ -148,12 +148,15 @@ bool GlobalRWLock::lockWrite(thread_db* tdbb, SSHORT wait)
++pendingLock;
}
COS_TRACE(("(%p)->lockWrite LCK_lock readers(%d), blocking(%d), pendingWriters(%d), currentWriter(%d), lck_physical(%d), pendingLock(%d)",
this, readers, blocking, pendingWriters, currentWriter, cachedLock->lck_physical, pendingLock));
if (!LCK_lock(tdbb, cachedLock, LCK_write, wait))
{
ISC_STATUS* const status = tdbb->tdbb_status_vector;
if ((wait == LCK_NO_WAIT) || ((wait < 0) && (status[1] == isc_lock_timeout)))
fb_utils::init_status(status);
Attachment::CheckoutLockGuard counterGuard(att, counterMutex, FB_FUNCTION, true);
--pendingLock;
@ -266,6 +269,10 @@ bool GlobalRWLock::lockRead(thread_db* tdbb, SSHORT wait, const bool queueJump)
if (!LCK_lock(tdbb, cachedLock, LCK_read, wait))
{
ISC_STATUS* const status = tdbb->tdbb_status_vector;
if ((wait == LCK_NO_WAIT) || ((wait < 0) && (status[1] == isc_lock_timeout)))
fb_utils::init_status(status);
Attachment::CheckoutLockGuard counterGuard(att, counterMutex, FB_FUNCTION, true);
--pendingLock;
return false;

View File

@ -265,7 +265,12 @@ void PCMET_lookup_index(thread_db* tdbb, jrd_rel* relation, index_desc* idx)
// if we can't get the lock, no big deal: just give up on caching the index info
if (!LCK_lock(tdbb, index_block->idb_lock, LCK_SR, LCK_NO_WAIT))
{
// clear lock error from status vector
fb_utils::init_status(tdbb->tdbb_status_vector);
return;
}
// whether the index block already existed or was just created,
// fill in the cached information about the index