[erlang-questions] Couple of questions about mnesia locking

[Hynek Vychodil]

Write operation will require aquiring write lock, obviously.

On Sat, Apr 4, 2009 at 7:54 PM, ryeguy <ryeguy1@REDACTED> wrote:

> Hmm..well what if we had a transaction where we add to a bank account
> balance. You obviously read the balance then increment it.
>
> If NodeA and NodeB both have replicas of the table containing the
> balance, couldn't this happen:
>
> NodeA reads balance of 5
> NodeB reads balance of 5
> NodeA writes balance of 10
> NodeB writes balance of 15
>
> Since there is no read lock on each node? I'm assuming it would work
> like this because, if I understand correctly, the locks are acquired
> AS the transaction processes, and not the second the transaction fun
> is executed, right?
>
> In this situation, is the solution to simply just grab a write lock on
> the record when reading it?
> This poses another question: how do you acquire a write lock on a
> record when you do an index read?
>
> On Apr 4, 7:31 am, Richard Andrews <bbm...@REDACTED> wrote:
> > > If I wanted to check if a username is in use before registering an
> > > account like this:
> >
> > > F=fun()->
> > > case is_username_available(User) of    %% does a mnesia:read to see if
> > > there is a record with that username
> > >     false -> throw(username_in_use);
> > >     true -> mnesia:write(User)
> > > end,
> >
> > > mnesia:transaction(F).
> >
> > > Don't I have a potential race condition here? Since there is no record
> > > to lock because it doesn't exist, how can mnesia guarantee another
> > > process isn't also going to write that same Username to the database?
> > > If I'm doing this wrong, what's the right way? A table lock (eww)?
> >
> > 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.
> >
> > Sharding/splitting the gatekeeper responsibility by eg. username first
> letter would quarantine the damage from a gatekeeper failure.
> >
> > > My second question is regarding a quote from the mnesia manual:
> > > "Write locks are normally acquired on all nodes where a replica of the
> > > table resides (and is active). Read locks are acquired on one node
> > > (the local one if a local replica exists). "
> >
> > > What does it mean read locks are acquired on one node? What would
> > > happen when a table is distributed? Wouldn't that defeat the purpose?
> >
> > A read lock on any node prevents a write lock from being acquired on that
> item.
> > 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.
> >
> > --
> >   Rich
> >
> >       Enjoy a safer web experience. Upgrade to the new Internet Explorer
> 8 optimised for Yahoo!7. Get it now.
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questi...@REDACTED://
> www.erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



-- 
--Hynek (Pichi) Vychodil

Analyze your data in minutes. Share your insights instantly. Thrill your
boss.  Be a data hero!
Try Good Data now for free: www.gooddata.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090404/61c5f859/attachment.htm>