Improve mnesia_locker for large amounts of locks in the same transaction

I've found that taking a large amount (from 1000 and upwards) of mnesia
locks in the same transaction scales poorly. It seems to boil down to
mnesia_locker keeping a bag ets table to store the reference between a
transaction id (TID) and all locks held by the transaction.

Changing the ets table to an ordered set table, and tweaking the code to
preserve the same semantics seems to dramatically improve the scaling.

If you need a test program to show the effect, just tell me.

Links:

https://github.com/erlang/otp/pull/382

git fetch [email protected]:gorillainduction/otp.git
improve_mnesia_locker_complexity

https://github.com/gorillainduction/otp/compare/erlang:maint...improve_mnesia_locker_complexity
https://github.com/gorillainduction/otp/compare/erlang:maint...improve_mnesia_locker_complexity.patch

_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches