Subject | Re: [Firebird-Architect] PR and EX locks compatibility |
---|---|
Author | Jim Starkey |
Post date | 2013-11-05T21:29:50Z |
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.
With enough work and complexity, maybe the page precedence mechanism
could be adapted to resolve/detect/avoid conflicts. The question
remains whether copying every page when it is write locked is a good use
of memory or cycles.
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.
With enough work and complexity, maybe the page precedence mechanism
could be adapted to resolve/detect/avoid conflicts. The question
remains whether copying every page when it is write locked is a good use
of memory or cycles.
On 11/5/2013 3:24 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Just a thought: currently if a page in shared cache is locked for reading, a writer is
> standing in queue and waiting. What if page manager instead of that create a copy of the
> page and while it is still read by someone, writer will get the lock successfully. Can
> this make the Bird faster under load?
>