> The cool thing was I also wrapped the database lock under the distributed in memory lock so in the case of a net split the database’s lock’s got my back. In normal circumstances it made things scalable because the in memory lock would prevent the client from connecting to the database until the in memory lock was let go.

how did you coordinate this, since both are different systems altogether?

edit: I went through the video at 1.5x speed and I understand it now. This is the grand idea:

1. Use a separate distributed lock manager, get lock on the wallet. This lock is in-memory

2. Start transaction on DB and make changes

3. Release the lock

4. Other transactions wait at #1, since they can't get the lock. Thus this reduces the overall load on the DB.

This is cool though!