Stas Bekman [mailto:[EMAIL PROTECTED]] wrote:
> As the person who has discovered this bad flaw in DB_File docs and made
> sure that the right thing will be done, may be David will have a time to
> go further and check up on this issue. I would definitely do it myself,
> but there so many things I've to do, I just cannot do it now :(
>
> Or anybody else who wants to contribute to the community by a little
> effort? Just grab the tgz which represents the problem, from the url
> posted a few days ago by David and see if you can tackle this issue of the
> correctness of using sync and the actual benchmarking to check whether
> it's faster to do tie/untie or using sync and locking...
>
> Thanks a bunch!
I have done some investigation of the sync method in DB_File and this is
what I have determined: the sync method only writes cached information out
to disk. Information already cached in the process is not invalidated
causing a re-read from the disk.
My example program and the annotated strace can be found here for anyone
that wants to see the details:
http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.pl
http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.strace01
Here is what I think this means for locking:
If you want to downgrade a lock from exclusive to shared, sync the database
and change the lock status. This will allow other readers access to a
fully-written database. No one else will be allowed to write the database
(requiring your process to have invalidated any cached data) until you have
released the shared lock. No problem there.
If you want to upgrade a lock from shared to exclusive, simply request this
upgrade from the locking subsystem and write to the database once an
exclusive lock has been acquired. Since the database has been in a shared
lock since it was opened no one has written to it. Therefore, no
invalidation of cached data is required since the database on disk has not
changed.
Beware when upgrading shared locks to exclusive locks that: (a) you don't
get a deadlock with two shared locks trying to upgrade at the same time, and
(b) if your locking layer resolves this deadlock by denying one of the
upgrade requests, make sure your program handles that appropriately.
I imagine one would handle a lock upgrade failure by closing the database
and then requesting an exclusive lock. Perhaps one would want to rollback
changes made to the database or otherwise prepare for this transition.
I'd rather just grab an exclusive lock at the beginning if I know there's a
chance of needing to write the database later on. Or just close and re-open
the database instead of trying the upgrade at all. Everyone may have their
own particular application that needs something special. However, I'd rather
just use a RDMS if I'm running into this level of locking details.
Then again, none of that is related to sync as it is not required for a lock
upgrade. :-)
OK, summary:
(1) Seems to me that sync should only be used for downgrading exclusive
locks to shared, and that sync is well suited for this task.
(2) You can upgrade locks from shared to exclusive without sync, but you
might want to avoid needing to upgrade locks because of deadlock problems.
Hope this helps.....
(Thanks for the break from the Windows2k nightmare. Why does Oracle
Enterprise Manager only run on w2k?! Well, back to work :-)
David Harris
President, DRH Internet Inc.
[EMAIL PROTECTED]
http://www.drh.net/
