Vlad Khorsun escreveu:

>> If they can't, you will end in
>> something very like I proposed with locks. (Locks solution may also be
>> adapted to allow execution continuing and locks acting only in prepare
>> and DDL changes)
>>
>
> Perhaps we will combine both proposals and take best from them :)
>

It would be the ideal thing. ;-)

>>>> Att1: create procedure P3 as begin execute procedure P1; end
>>>> Att1: could execute P3
>>>>
>>>>
>>> New instance of P3 will call old (current) instance of P1
>>>
>>>
>>>
>>>> Att2: alter P1 parameters
>>>> Att2: could execute P1
>>>>
>>>>
>>> New instance of P1 executed
>>>
>>>
>>>
>>>> Att1: commit
>>>> Att2: commit
>>>>
>>>>
>>> P3's internal request will be invalidated and engine would load and parse
>>> P3's BLR on next run.
>>>
>> And parse will not work, cause it will not compile.
>>
>
> Do you mean - it will not compile because of not compatible change of
> P1 signature (input\output params) ?
>

Yes.

> If first - how would your offer prevent not compatible change of P1 if P3
> already existed and even was not loaded at time of alter of P1 ? This is up to
> dependencies tracking, i'd said.
>

I think when altering P3, global exclusive lock should be acquired on it
and global shared lock acquired on P1. P1 will not be alterable until P3
transaction is committed.

If we figure out the way this locks interacts with prepared statements
invalidation and object ref. counters for execution, we'll have
semantics between what me and you proposed.

Versioned changes is not the important thing but the important things is
how and when others receive errors about DDL changes and if others
prevent or not DDL changes.

>
>> It's bad if it's not
>> marked with RDB$VALID_BLR = FALSE. It's not good even if it's marked.
>>
>
> Who prevent us to set RDB$VALID_BLR to FALSE if BLR parse failed ?

It was introduced to be marked as false as soon the object was
invalidated to not have surprises on execution, and marked as true when
it's parseable.


Adriano