dynamobi/dynamobi — Issue #609: [FRG-263] code cache concurrency problem with stale and non-cachable SQL statements
Author: dynamobi-build
Created: 2011-12-30 03:38:20+00:00
State: open
Labels: FRG, Statement Processing

[reporter="jvs", created="Wed, 11 Apr 2007 16:06:31 -0500 (GMT-05:00)"]
Zelaine Fong wrote:

> John,

>

> One of the other failures I'm looking at in last night's nightly run is

> a failure in one of the large concurrency tests.

> luciddb/test/sql/concurrency/large-delete2 fails with an assert while

> trying to discard a cache entry that's pinned by another thread.

>

> Working backwards from the stack, I think what's happening is the

> following:

>

> 1) The test prior to large-delete2, large-delete1, creates a table t100.

> One of the statements it executes in the test is "delete from t100

> where kseq = 1". At the end of the test, t100 is dropped.

>

> 2) large-delete2 then creates t100 again. It then also issues a "delete

> from t100 where kseq = 1" statement. That statement is already in the

> Farrago statement cache as a result of large-delete1, but since the t100

> it's referencing is the original t100 that's been dropped,

> FarragoDatabase.isStale() returns true, and

> FarragoDatabase.prepareStmtImpl() then tries to discard the out-of-date

> cache entry by calling codeCache.discard().

>

> The discard() asserts because the entry's pincount != 0. I think that's

> because there are other threads in large-delete2 that are also trying to

> execute "delete from t100 where kseq = 1". Therefore, they have the

> entry pinned before it's been detected that the entry is out-of-date.

>

> I don't think any of the changes I made for versioning changed this, and

> it's probably just a race condition that we've been unlucky never to

> have hit. In the nightly run, it only failed on the Redhat run. The

> Ubuntu one passed. And I haven't been able to reproduce it on tikki01-red.

>

> Does this sound right?

>

> -- Zelaine

>