| Age | Commit message (Collapse) | Author |
|---|
|
Bad timing could lead to hanging transactions after a mnesia down from a
node with sticky locks.
Excellent bug report from janchochol
Situation:
* node A and B have copies of table T
* node A ows sticky of table T
* node A goes down (e.g. crash)
* node B tries to perform transactional operation on table T
(e.g. mnesia:select)
In this situation there is possibility that first (and maybe other)
transaction on node B will hang indefinitely.
This is caused by race condition, when transaction process send lock
request operation to node A and waits for reply. When node A is down
it will never send reply, so process on node B will be stuck
forever.
Reason is that message sent to mnesia_locker gen_server from
mnesia_locker:mnesia_down can be received after mnesia_locker gen_server
already replies to transaction processes with {switch, N, Req} and
node N is down.
Monitoring remote process when sending request to other node should
be safe solution.
|
|
|
|
If a transaction releases a write, it can be deleted directly since no read locks
or other write locks can be present
|
|
|
|
5% faster on tpcb
|
|
Switch to ordered_set so match_object matches partially bound keys,
more efficient.
|
|
Read from where_to_read otherwise bad data may read during
move_table, where where_to_write is updated before where_to_read
and the table is available.
|
|
wread on locks stuck at non-local node could return unexpected value.
Thanks to Magnus Henoch who posted a nice testcase showing the bug.
|
|
|
|
|
|
|
|
|
|
Since the table loader also sets (table) write locks, a special
lock type, 'load', was needed. Unfortunately, this affects mnesia
activity callbacks that redefine the lock operation.
|
|
With help from Kostis
|
|
Resolve name clash with auto-imported BIF error/2.
|
|
|
