Hi!

Both in SS and CS we have one DSQL metadata cache for each attachment to
a database.

In SS, when one attachment drop a object, it marks that object as
dropped for all attachments.
It's easy as all caches are in the same address space.

In CS, dropped objects remain in caches of others attachments and causes
things like that, consider c1 and c2 as two connections to the same
database.
--------------
c1: isql
c1: create database 'x.fdb';
c2: isql x.fdb
c1: create table t (n integer);
c2: select * from t;
c2: commit;
c1: drop table t;
c2: commit;
c2: create table t (n integer);
c2: select * from t;
Statement failed, SQLCODE = -104
invalid request BLR at offset 28
-table id 128 is not defined
--------------

You should note the last two commands. They come from the same connection.
The table should be accessible but isn't because the cache has a old
reference for it.

Solutions like remove the table from the cache when you are creating it
doesn't work in general case as problems could be caused with more than
two attachments too.

I've research a solution for the case. Here is it.

A new lock is created (dsql_cache_lock), and when one starting reading
the cache, it acquires a shared lock on dsql_cache_lock and get a flag
indicating if the cache is obsolete.

If the cache is obsolete, it clears the cache, i.e., remove every
reference but everything continues allocated in the pool. I don't like
this lost references but I don't know what can be do.
In SS a similar thing already occur per object, not entire cache.

When one are dropping a object, it acquires a exclusive lock on
dsql_cache_lock, notifying all others attachments through AST to release
his shared lock and mark his cache as obsolete.

In that way, the SS and CS cache works in some different way internally
but with the same semantics.

While all that is needed only for DSQL, our lock handler (LCK) is engine
specific, so a internal y-valve call (like we already have for intl) was
introduced to play with dsql_cache_lock through DSQL. Subject to be
removed in Vulcan with DSQL and the engine working together.

Comments? Suggestions? Objections?


Adriano