3 ms·
> 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 n
by avinassh 3y ago
> 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!
- zacksiri 3y agoYou can see this video. https://youtu.be/v-n8L-DiPL4 https://youtu.be/v-n8L-DiPL4 Update: Thx for going through it! You got the idea.
- hiram112 3y agoI watched the beginning of the video but it's over an hour and relatively slow going. I don't know Elixer or frameworks around it. But I'm guessing you basically just used something like Zookeeper to do distributed locks at the API call level. Only when they got that lock would they then be given DB access, which then ensured the DB itself wouldn't grind to a halt as many calls were all locking tables at the same time. So what was the solution to returning status to the caller? Did you just give them a ticket which they could then poll status later? Meanwhile, the individual servers just put the requests on a local queue and spin in a thread till they get the lock from Zookeeper (or similar) and can access the DB?