Support for readers-writers lock semantics

[trydzynski-zen]

Hi! This link works great for serializing updates. In my application, I'm doing some reloads and invalidations after an update. I could serialize them as well, but that adds latency which I don't need, as reads could happen in parallel. So for now, I'm using this link only for updates, and I use some workarounds to trigger reloads at the right time.

It would be a nice feature to be able to decorate writes and reads differently, and then serialize them so that when writing happens, only one writing request at a time is possible (and readers wait), but when reading, all readers can progress in parallel.

[helfer]

Hm, that's an interesting idea @trydzynski-zen. Can you share a bit more about how your application works, specifically:

• How do the components making the updates and queries relate to each other
• How are you calling the link stack? Directly from components or via some other client?
• What are the workarounds you're using for triggering reloads at the same time?

I agree that it could be useful, but implementing rw lock semantics would make the link quite a bit more complicated, and we'd possibly have to start thinking about things like fairness and starvation.

[trydzynski-zen]

Disclaimer: the code base is partially legacy, so we could argue that there are better ways, and I would agree :).

Thanks for the interest. To answer your questions...

This part of the app is something like a reporting/searching interface. There are metadata about filtering, sorting, etc, and there are the data with results. Updates (mutations) are fired from Redux actions (redux-saga). UI components that read data are connected to apollo-link thanks to our legacy implementation of something just like apollo-react.

There are a few reading components. They should fetch their data in parallel (that's why I don't use apollo-link-serialize for the reads).

So when doing updates, I don't really want to know what are the reading components. Knowing that would, IMHO, defeat the purpose of using something like apollo-react.

Firing reads after an update is easy, and not related to request queues, so I'll skip that. Now, back to readers-writers locks. The tricky part is to block updates while reading data.

When components are fetching data, I should not update the metadata. Since there are several reads happening in parallel, If I updated the metadata while the reads were in progress, I could affect some of those reads and get inconsistent results.

Workarounds...

So right now I'm hacking the interface to disable UI controls while fetching the data - this looks terrible, and makes the UI less friendly. And partially I am ignoring this problem, as there is always one final data fetch after the last mutation. Whatever inconsistent state there is, shows up only for a few seconds... but that can still annoy the users... which important data show weird stuff for split moments, you may lose trust in the system.