[erlang-bugs] Funny behaviour of dirty_next in mnesia?

[Ulf Wiger]

Well, it's the same process that's calling the functions, so usually one would expect a sequential view of the data.

However, in the case of transactions vs dirty, it's not quite as clear-cut, and I don't think the documentation has anything to say about this. except to hint that it's unhealthy to mix dirty and transactions too much.

I would agree with John that this behaviour is surprising on the surface of it. Perhaps using mnesia:activity(sync_transaction, F) or mnesia:sync_transaction(F) * would make a difference? I'll admit that I haven't tried.

* According to the User Guide, "Synced transactions waits until all active replicas has committed the transaction (to disc) before returning from the mnesia:sync_transaction call."

BR,
Ulf W

On 17 May 2011, at 23:32, Ahmed Omar wrote:

> Well, it's not the same process. When mnesia find out that :
> - there are N of updates to commit, 
> - the protocol to use it async 
> - the node of tid  is not the local node 
>  
> it spawns a new process to do the commit.
> 
> On Tue, May 17, 2011 at 10:44 PM, John Hughes <john.hughes@REDACTED> wrote:
>  
>  
> From: Ahmed Omar
> 
> I'm not a mnesia expert, but i THINK the race condition is in the test not mnesia. transaction is still being committed and logged, when the dirty read is issued. if you add a sleep in between or better if you use mnesia:sync_transaction (http://www.erlang.org/doc/man/mnesia.html#sync_transaction-3) instead of mnesia:transaction, the test will fail, i.e the case disappear
> isn't that the expected behavior or am i missing something?
>  
> Adding a sleep (I added a second) or using sync_transaction instead changes the behaviour to what I would expect, so it sounds as though you may be right about what's happening. But even so, it's not the behaviour I would expect, at least!
>  
> There isn't any concurrency in the test. There's only distribution--and there's only one copy of the table, on the slave node. Isn't it weird that when the transaction returns, the SAME process that ran the transaction does not see its side effects?
>  
> By the way, if I swap the last two operations (which Ulf Wiger suggested), then I see the same kind of behaviour... but now the first operation (which is now a dirty_read) actually retrieves the deleted tuple from the table, while the second operation (now the dirty_next) sees no keys in the table.
>  
> This doesn't happen if the table is on the same node as the test is executed on, so distribution certainly is not transparent in this case.
>  
> John
>  
> 
> 
> 
> On Tue, May 17, 2011 at 6:57 PM, John Hughes <john.hughes@REDACTED> wrote:
> QuickCheck turned up another case of odd behaviour at Klarna.
>  
> The test runs mnesia on two nodes, creates a table on the OTHER node, then adds and deletes a record. After this the record is indeed not IN the table, but dirty_next finds its key anyway! Surely it shouldn't?
>  
> Here's the test:
>  
> test() ->
>     Slave = start_mnesia_with_slave(),
>     {atomic,ok} = mnesia:create_table(rec,[{type,set},
>         {disc_only_copies,[Slave]}]),
>     ok          = mnesia:dirty_write({rec,4,1}),
>     %% The next command MUST be done in a transaction, otherwise dirty_next works
>     {atomic,ok} = mnesia:transaction(fun()->mnesia:delete_object({rec,4,1}) end),
>     %% Here's the problem: dirty_next returns 4, but this key is not in the table!
>     4           = mnesia:dirty_next(rec,0),
>     []          = mnesia:dirty_read(rec,4).
> I'm starting mnesia and the slave node like this:
>  
> start_mnesia_with_slave() ->
>     {ok,Dir} = file:get_cwd(),
>     ok = error_logger:tty(false),
>     mnesia:stop(),
>     ok = error_logger:tty(true),
>     delete_file("mnesia"),
>     delete_file("slave"),
>     ok = file:make_dir("mnesia"),
>     ok = file:make_dir("slave"),
>     Slave = slave(),
>     ok = application:set_env(mnesia,dir,Dir++"/mnesia"),
>     ok = rpc:call(Slave,application,set_env,[mnesia,dir,Dir++"/slave"]),
>     ok = mnesia:create_schema([node(),Slave]),
>     ok = mnesia:start(),
>     ok = rpc:call(Slave,mnesia,start,[]),
>     Slave.
>  
> slave() ->
>     case slave:start_link(net_adm:localhost(),"slave") of
>  {ok,Slave} ->
>      Slave;
>  {error,{already_running,Slave}} ->
>      Slave
>     end.
> I also have code to delete a file or directory, easy on Linux, darn difficult on Windows. You don't need this really, just run the test in an empty directory.
>  
> delete_file(Name) ->
>     case filelib:is_dir(Name) of
>  true ->
>      [delete_file(Name++"/"++X) || X <- list_dir(Name)],
>      file:del_dir(Name),
>      delete_file(Name);
>  {error,eaccess} ->
>      delete_file(Name);
>  {error,enoent} ->
>      io:format("Could not find ~p\n",[Name]),
>      ok;
>  false ->
>      case file:delete(Name) of
>   {error,enoent} ->
>       ok;
>   {error,eacces} ->
>       io:format("Could not access ~p\n",[Name]),
>       delete_file(Name);
>   ok ->
>       delete_file(Name)
>      end
>     end.
>  
> list_dir(Name) ->
>     case file:list_dir(Name) of
>  {ok,Files} ->
>      Files;
>  {error,eacces} ->
>      io:format("Could not list directory ~p\n",[Name]),
>      list_dir(Name);
>  {error,enoent} ->
>      io:format("Could not find directory ~p\n",[Name]),
>      []     
>     end.
> John
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
> 
> 
> 
> 
> -- 
> Best Regards,
> - Ahmed Omar
> http://nl.linkedin.com/in/adiaa
> Follow me on twitter
> @spawn_think
> 
> 
> 
> 
> -- 
> Best Regards,
> - Ahmed Omar
> http://nl.linkedin.com/in/adiaa
> Follow me on twitter
> @spawn_think
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20110518/af7109ca/attachment.htm>