Subject | RE: [Firebird-Architect] Metadata locking policy and caching |
---|---|
Author | Paul Hope |
Post date | 2008-08-07T15:49:57Z |
Hello Adriano
dependencies, make the change then reinstate dependencies.
All of our customers use many different application functions and typically
none are used intensively by several users at once, so most of the time most
of the procedures are not being accessed. Unlike an example I was once
given of a call center where a few procedures may be used intensively by
many users and there may be no time when the procedures are free.
The safest approach may be to shutdown, but - it can be very difficult with
a geographically spread client working inconsistent hours, also we have not
had a problem in 13 years of Interbase and Firebird SS so the engine must
have the ability to manage it. So on balance the benefits of making changes
to the live system massively outway what in our experience has been zero
problems ;-)
I was told some time ago - I think by one of the developers - that SS has a
mechanism for caching changes until the target objects are released. I
imagined this as like a transaction with the ability to wait around.
Regards
Paul Hope
> Paul Hope escreveu:Yes - we use DBComparer in IBExpert - or manually create a script to empty
> > I hang around on this group only half understanding most of what is
> > discussed - but this latest discussion is ringing alarm bells ...
> >
> > To us it is absolutely essential that the ability to update
> metadata
> > on a live database remains at least as felexible as it is
> now (FB1.5
> > SS). There is no way we can ask users to shut down while we make
> > minor updates. We've been doing this without problem for
> the past 13 years.
> >
> Well, I consider shutdown the safest approach to do metadata
> changes *now*. :-)
>
> Are you aware that if Proc0 calls Proc1, Proc0 was already
> called be any connection, and you change Proc1, Proc0 will
> call the old version of Proc1?
>
> Did you use any tool that recompile (recreate) dependencies?
>
dependencies, make the change then reinstate dependencies.
All of our customers use many different application functions and typically
none are used intensively by several users at once, so most of the time most
of the procedures are not being accessed. Unlike an example I was once
given of a call center where a few procedures may be used intensively by
many users and there may be no time when the procedures are free.
The safest approach may be to shutdown, but - it can be very difficult with
a geographically spread client working inconsistent hours, also we have not
had a problem in 13 years of Interbase and Firebird SS so the engine must
have the ability to manage it. So on balance the benefits of making changes
to the live system massively outway what in our experience has been zero
problems ;-)
I was told some time ago - I think by one of the developers - that SS has a
mechanism for caching changes until the target objects are released. I
imagined this as like a transaction with the ability to wait around.
Regards
Paul Hope