Subject | Re: [Firebird-Architect] Invalidating Objects was: Statement Cache [was: User name SYSDBA] |
---|---|
Author | Jim Starkey |
Post date | 2005-08-31T16:41:42Z |
Leyne, Sean wrote:
never invalidate running requests based on a metadata change, so
dropping a compiled statement referencing a changed table is all that is
necessary to prevent it from being re-used. Existing instances are
prefectly safe to continuing running, and are, in fact, no different
from the current behavior whethere compiled statements are not cached.
What's the big deal? I haven't heard anybody argue that we should hunt
down and kill running requests against a table whose metadata has
change. Why would instances of a previous compiled statement me any
different?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>I brought it up, because Jim said there would never be a need to markFor the life of me, I can't figure what this argument is all about. We
>cached statements as invalid -- which would not be true if this new
>feature were to be implemented.
>
>I think the new feature will have an impact on the statement cache, but
>don't have a problem discussing it separately.
>
>
never invalidate running requests based on a metadata change, so
dropping a compiled statement referencing a changed table is all that is
necessary to prevent it from being re-used. Existing instances are
prefectly safe to continuing running, and are, in fact, no different
from the current behavior whethere compiled statements are not cached.
What's the big deal? I haven't heard anybody argue that we should hunt
down and kill running requests against a table whose metadata has
change. Why would instances of a previous compiled statement me any
different?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376