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 <[email protected]>: > > 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 > [email protected] > http://erlang.org/mailman/listinfo/eeps >
_______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
