Locking B-tree files vs. locking B-trees

Whenever an item is inserted or deleted in a B-tree by one user, the whole B-tree must be locked to prevent simultaneous changes by other users. Locking just one node in a B-tree is insufficient because the node might have to split or concatenate with its neighbor, causing edits to propagate through the B-tree to other unlocked nodes.

BTP/Branches #1 demonstrated locking by locking the whole B-tree file any time any of the three B-trees in the file were being updated. Actually, it is only necessary to lock the single B-tree being updated, so that other B-trees in the same file can be updated at the same time. To lock just one B-tree, you would have to assign a different lock for each B-tree, or use some similar mechanism. However, note that all B-trees in one file share the item named NEXT.ID, which lets BTPINS assign new node ID numbers in the file. That means that if you decide to lock only individual trees instead of locking the whole B-tree file, you must use a READU instead of a READ in lines 006, 040, and 073 of BTPINS where the NEXT.ID item is accessed.