<div>you got it :-) that's what I tried to explain: read, modify and update must be a single atomic operation.</div><div>cheers</div><div>balz<br><br><div class="gmail_quote">On Wed, Feb 2, 2011 at 7:30 PM, Cedric Staub <span dir="ltr"><<a href="mailto:cedric.staub@wyona.com">cedric.staub@wyona.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Feb 02, 2011 at 06:41:26PM +0100, Balz Schreier wrote:<br>
> 1) Regarding "Build a locking mechanism into Yarep": How would that really<br>
> help?<br>
> Talking of a cluster, we mean multiple JVMs, each of them are running Yarep,<br>
> all accessing a shared file in the filesystem.<br>
><br>
> If you want to solve it with writing a lock file (like Lucene does), then<br>
> you need to be sure that the lock file gets written synchronously and in a<br>
> single atomic operation (form the JVM down to the harddrive, no buffers,<br>
> etc.).<br>
> NFS can not guarantee that.<br>
<br>
</div>I was thinking of building the locking into Yarep, e.g. the Yanel nodes<br>
could communicate with each other in the network in order to implement a<br>
form of distributed locking. I didn't say it's an easy task though, but<br>
it would allow the locking to be independent from the backend.<br>
<div class="im"><br>
> What I read in the Lucene Book (Lucene in Action, 2nd Edition 2010) is the<br>
> following approach:<br>
> - The JVMs (and therefore Yarep too) do not write to the local file system<br>
> (reading is ok though), instead they call a central "write service". Of<br>
> course you have a single point of failure (for writing, reading continues to<br>
> work fine). But you don't have to deal with thinking about locking etc.<br>
><br>
> 2) Regarding "Simply use a backend that can do concurrent writing": How do<br>
> you solve this then:<br>
><br>
> assume you have two JVMs running your app, both with the ability to write<br>
> nodes.<br>
> assume that at the same time, both JVMs read a file with a content element A<br>
> in it.<br>
> The first JVM adds B into the file (A,B), the second JVM adds C into the<br>
> file (A,C).<br>
> But "adding" means: read from yarep, modify, write back.<br>
> So even if you have proper locking in place, what do you end up with on the<br>
> filesystem? A,C or A,B ? What should be in the file is of course A,B,C or<br>
> A,C,B... and I think that this can only be done with a single "write"<br>
> service (equal to writing into the same database).<br>
<br>
</div>How can you achieve this with a simple writing service?<br>
<br>
You'll still have the same problem:<br>
* Process A reads contents<br>
* Process B reads contents<br>
* Process A modifies and sends to write service<br>
* process B modifies and sends to write service<br>
<br>
You will still end up with a file that only contains the modifications from<br>
process B and the modifications from process A will be lost. You would<br>
have to make the whole sequence - read, modify, write - atomic. I don't<br>
see how the writing service does that, but maybe I just don't understand<br>
what you mean by writing service exactly. Can you elaborate on the idea?<br>
<br>
Cheers<br>
<div><div></div><div class="h5">Cedric<br>
--<br>
Yanel-development mailing list <a href="mailto:Yanel-development@wyona.com">Yanel-development@wyona.com</a><br>
<a href="http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development" target="_blank">http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development</a><br>
</div></div></blockquote></div><br></div>