I know a write lock would eventually be acquired, but aren't locks acquired AS the functions in the transaction are called? Like wouldn't it do this:<br><br>
NodeA reads balance of 5; gets read lock on record<br>
NodeB reads balance of 5; gets read lock on record<br>
NodeA writes balance of 10; gets write lock on record<br>
NodeB writes balance of 15; gets write lock on record<br>^ Obviously this would be bad<br><br>Or does mnesia read the entire transaction first and then apply all of the locks before doing any of the actions? I don't think this is the case because then functions such as mnesia:wread would be necessary.<br>
<br><div class="gmail_quote">On Sat, Apr 4, 2009 at 3:59 PM, Hynek Vychodil <span dir="ltr"><<a href="mailto:vychodil.hynek@gmail.com">vychodil.hynek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Write operation will require aquiring write lock, obviously.<br><br><div class="gmail_quote">On Sat, Apr 4, 2009 at 7:54 PM, ryeguy <span dir="ltr"><<a href="mailto:ryeguy1@gmail.com" target="_blank">ryeguy1@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hmm..well what if we had a transaction where we add to a bank account<br>
balance. You obviously read the balance then increment it.<br>
<br>
If NodeA and NodeB both have replicas of the table containing the<br>
balance, couldn't this happen:<br>
<br>
NodeA reads balance of 5<br>
NodeB reads balance of 5<br>
NodeA writes balance of 10<br>
NodeB writes balance of 15<br>
<br>
Since there is no read lock on each node? I'm assuming it would work<br>
like this because, if I understand correctly, the locks are acquired<br>
AS the transaction processes, and not the second the transaction fun<br>
is executed, right?<br>
<br>
In this situation, is the solution to simply just grab a write lock on<br>
the record when reading it?<br>
This poses another question: how do you acquire a write lock on a<br>
record when you do an index read?<br>
<div><div></div><div><div><div></div><div class="h5"><br>
On Apr 4, 7:31 am, Richard Andrews <<a href="mailto:bbm...@yahoo.com.au" target="_blank">bbm...@yahoo.com.au</a>> wrote:<br>
> > If I wanted to check if a username is in use before registering an<br>
> > account like this:<br>
><br>
> > F=fun()-><br>
> > case is_username_available(User) of %% does a mnesia:read to see if<br>
> > there is a record with that username<br>
> > false -> throw(username_in_use);<br>
> > true -> mnesia:write(User)<br>
> > end,<br>
><br>
> > mnesia:transaction(F).<br>
><br>
> > Don't I have a potential race condition here? Since there is no record<br>
> > to lock because it doesn't exist, how can mnesia guarantee another<br>
> > process isn't also going to write that same Username to the database?<br>
> > If I'm doing this wrong, what's the right way? A table lock (eww)?<br>
><br>
> You could use a gatekeeper - a singleton process on only one node which is allowed to create usernames. Creators make a request to the gatekeeper which serialises the requests and therefore prevents the race. The problem then shifts to process registration consistency and takeover in the case of the gatekeeper failure.<br>
><br>
> Sharding/splitting the gatekeeper responsibility by eg. username first letter would quarantine the damage from a gatekeeper failure.<br>
><br>
> > My second question is regarding a quote from the mnesia manual:<br>
> > "Write locks are normally acquired on all nodes where a replica of the<br>
> > table resides (and is active). Read locks are acquired on one node<br>
> > (the local one if a local replica exists). "<br>
><br>
> > What does it mean read locks are acquired on one node? What would<br>
> > happen when a table is distributed? Wouldn't that defeat the purpose?<br>
><br>
> A read lock on any node prevents a write lock from being acquired on that item.<br>
> A write lock must be acquired on *all* nodes so it is sufficient to take a read lock on any one node to block a write lock from being acquired.<br>
><br>
> --<br>
> Rich<br>
><br>
> Enjoy a safer web experience. Upgrade to the new Internet Explorer 8 optimised for Yahoo!7. Get it now.<br></div></div>
> _______________________________________________<br>
> erlang-questions mailing list<br>
</div></div>> erlang-questi...@erlang.orghttp://<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<div><div></div><div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br><br>Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero!<br>Try Good Data now for free: <a href="http://www.gooddata.com" target="_blank">www.gooddata.com</a><br>
</blockquote></div><br>