The db_record_lock_factory just uses normal $DB calls, and these are either committed or rolled back if done inside a transaction.

What this effectively means is that many cases the locking is done at the DB row lock level, and not inside the php polling loop. Which means that the lock timeout in php land is not honored when it is declared to be supported. In some cases it means that the whole table is locked so that it blocks unrelated locks in unrelated lock types. It can also throw db exceptions when it should just return false.

The transaction stuff is a small edge case but it isn't documented as not being valid. So I think we should test for it. The problem is we cannot unit test it, we need different php processes. In fact none of the locks are actually properly tested at all for the same reasons.

I'm not sure what is needed, just a wiki update or actual code?