Subject | Re: [Firebird-Architect] PR and EX locks compatibility |
---|---|
Author | Jim Starkey |
Post date | 2013-11-06T16:14:30Z |
[This may be a duplicate]
Sure. Somebody gets a stale copy of a data page with a fragmented
record. When it goes to get the fragment, it finds that it isn't there
any more. Bug check.
Locks are required to enforce careful write, which guarantees that under
all circumstances de facto pointers to objects will always be deleted
before the object pointed to. When you introduce stale page copies, all
bets are off.
Sure. Somebody gets a stale copy of a data page with a fragmented
record. When it goes to get the fragment, it finds that it isn't there
any more. Bug check.
Locks are required to enforce careful write, which guarantees that under
all circumstances de facto pointers to objects will always be deleted
before the object pointed to. When you introduce stale page copies, all
bets are off.
On 11/5/2013 4:47 PM, Dimitry Sibiryakov wrote:
> 05.11.2013 22:29, Jim Starkey wrote:
>> Not likely to work at all. The problem is that pages updates are done
>> in a particular order so a client will always see a consistent database
>> (this applies to pages in memory as well as on disk). If the page
>> manager snapshots pages in the wrong order, a client will be apparent
>> garbage -- virtual pointers going nowhere, etc.
> Could you provide an example, please?..
>