Repository navigation
Replace locking with proper in-memory RW locking #1460
Description
The current locking system has many problems, which impact the performance of the server and other things.
- A file-based locking system is used, -- bug #1397
- There is only one lock for read and write operations
The last problem means that people cannot simultaneously read files, even when no writing is happening. If two people want to watch the same movie, they have to do it one after another!!
A locking system need to have the following properties:
- It is memory based
- It allows concurrent reads of the same file
- It only allows one request at a time to write the file
- While a request has write access to the file, no others can read or write it.
This a relatively common problem
Activity
NoelDeMartin commentedon Aug 2, 2020
I think this is also the cause of some problems I've been discussing in the solid forum.
In particular, making a GET request to a container causes the
purl:modifiedandposix:mtimeproperties to be modified. This is annoying because I'm using them to invalidate my application cache, and given that reads change them the cache becomes useless.bourgeoa commentedon Aug 7, 2020
I googled around and propose to try to build a lock system around : npm node-cache (https://www.npmjs.com/package/node-cache)and async-lock (https://www.npmjs.com/package/node-cache)
@timbl is it what you are expecting ?
Can anyone help to elaborate a bit more or propose an other strategy to solve this bug ? @RubenVerborgh @michielbdejong @jaxoncreed @jeff-zucker @Vinnl
I found lock.js in NSS to contain the actual lock/unlock mechanism (it uses proper-lockfile)
RubenVerborgh commentedon Oct 5, 2020
Solved by #1475