Hi, Adriano!
I skip most of the text in an answer just to make it faster readable.

On Monday 28 July 2008 03:37, Adriano dos Santos Fernandes wrote:
...
> I have prototype code that:
...
> - Removed DSQL metadata cache

Very good. Certainly, if it does not add so much regressions like it was with
vulcan after same step:)
...
> I should start saying that proposed locking policy is more restrictive
> than the many currently being used, but is MT-safe for SuperServer and
> should work identical in (Super)Classic. And as it's more restrictive,
> MON$ structure and actions may be extended to allow:
> - Monitoring of object locks acquired per prepared statement.
> - Kill prepared statement - it currently only can kill statement
> execution AFAIU.
>
> Main idea is that when an object is used in a prepared statement, a read
> lock is acquired on it. The lock is released only when the statement is
> unprepared. When altering or dropping an object, a write lock is
> acquired. If one attempts to acquire read and write lock for a specific
> object on the same attachment, an object in use error is thrown.

Hmmm...
Looks like that it means that procedure (and any other object in use) can
never be modified from other connection / transaction? If I'm not mistaken
with it, too many users will start crying 'regresion!!!' after this change.
Specially when we provide connection/transaction independent cache of
prepared statements.

Remember, we had to re-enable modification of procedure in use in next support
release version after it was disabled? I do not want to step on it once more.
........
> Thoughts?

Another idea, how to make metadata cacge work better. Imagine that we have
versions of the objects in the cache. A correct version of the object is
searched for according to VIO rules. This can let us have full support of
transactions in DSQL and not limit users with modification of only unused
objects. I.e. when object is modified, previous version of it remains
available for all transactions, started before it's committed.

Certainly, it seems to be harder to implement compared with your suggestion.
But I think it will provide us a lot of benefits in the future.