[eeps] New EEP 46: B-trees: balanced search trees of order n

[Ulf Wiger]

It's unclear to me how the how the persistence layer is supposed to ensure
consistency, especially in the face of concurrent updates.

Rather, from a quick read, it would seem as if the behavior is undefined in
such scenarios.

In the persistence example, the plugin is given only a subtree, but the
top-level function returns the whole updated tree. Thus, even if the update
is protected by a transaction, it's only each individual subtree
modification that's protected - not the whole tree, and not even the whole
update operation; if another process is modifying another subtree, it would
seem as if the trees held by the processes could become inconsistent,
including data loss.

(This raises the question whether the use of transactions is even
constructive in general, given that they are still costly. At the very
least, the EEP should address concurrency aspects.)

More generally, the API is modeled after gb_trees, which is a functional
API. Adding persistence introduces side-effects, bringing the API into a
whole new realm. My feeling is that the mismatch is not easily resolved.

BR,
Ulf W

2017-01-10 11:03 GMT+01:00 Raimo Niskanen <raimo+eeps@REDACTED>:

>
>     http://erlang.org/eeps/eep-0046.html
>     https://github.com/erlang/eep/blob/master/eeps/eep-0046.md
>
> It should show up shortly on www.erlang.org also.  I will chase someone
> responsible if not.
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20170111/fae5782d/attachment.htm>