Well, as far as I know, the mailboxes.db and other databases are only
opened and modified by the master process. But I'm not sure here.
But as your assumption sounds correct and because this seems to work
with cluster (and I fully believe you here, no question), your
assumption regarding the DBs somewhat must be correct.
Thanks!
I would be glad if some list member who has in depth knowledge here
could comment!
Best,
Daniel
Andrew Morgan schrieb:
On Tue, 1 Aug 2006, Daniel Eckl wrote:
Well, I don't have cluster knowledge, and so of course I simply
believe you that a good cluster system will never have file locking
problems.
I already stated this below!
But how will the cluster affect application level database locking?
That was my primary question and you didn't name this at all.
A database file which is in use is practically always inconsistent
until it's being closed by the database application.
That's why databases can be corrupt after an application crash and
have to be reconstructed.
When you have two applications changing the same database file, you
have a never ending fight, because every application thinks, the
database is inconsistent, but it's just in use by another application.
And every app will try to reconstruct it and so break it for the other
app(s).
It's like letting two cyrus master run on the same single node! It
will break in my opinion.
Can you shed some light on this subject?
I think the point here is that the situation you describe already occurs
all the time on a stand-alone Cyrus server. There are multiple imapd
processes accessing the mailboxes.db database concurrently. If you are
using Berkeley DB, it has an API to manage concurrent access. I assume
the same is true of skiplist and the other backend formats. I don't
know enough about the Berkeley DB internals to explain how it actually
works, but it does. :)
Andy
----
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
