Subject | Re: [firebird-support] Locking and disk activity |
---|---|
Author | Ann W. Harrison |
Post date | 2005-02-11T21:56:02Z |
Ivan Prenosil wrote>
page with the record to be written on commit, regardless of
architecture. In the general case, that doesn't matter much because the
record will have changed - that being the purpose of locking it - and
the change has to be written on commit.
However, in classic, a lock will cause a page to be written before the
commit if another process tries to access the record. As I vaguely
described, in SuperServer, the shared cache allows one connection to see
the current state of a page even if the most recent changes were made by
a different connection. In classic, my changes are visible to you only
if I write them to disk. So, if I lock a record, I have to write out
that page if anybody needs to see anything on it - even if I haven't yet
made any substantive changes.
Is that clearer?
>Ah. Locking a record creates a new record version which will cause the
>>Yes, but only if the page is in contention, which in turn depends on
>>whether you're using SuperServer or Classic.
>
> ???
page with the record to be written on commit, regardless of
architecture. In the general case, that doesn't matter much because the
record will have changed - that being the purpose of locking it - and
the change has to be written on commit.
However, in classic, a lock will cause a page to be written before the
commit if another process tries to access the record. As I vaguely
described, in SuperServer, the shared cache allows one connection to see
the current state of a page even if the most recent changes were made by
a different connection. In classic, my changes are visible to you only
if I write them to disk. So, if I lock a record, I have to write out
that page if anybody needs to see anything on it - even if I haven't yet
made any substantive changes.
Is that clearer?