Hacker News Reader

Comment by bluesign | Hacker News Reader

If the order of requests are retained, does it mean that if ‘mark thread as read’ request somehow fails on server side, all other requests will wait for it to be send until it gets success from server?

View on HN

We did something very similar to this and our solution was to have 2 classes of requests, those that require global ordering (creation of posts etc) and those that don’t. These second classes of requests can contain dependencies to each other to have a local ordering but don’t block any other requests.

Yeah I wondered if instead of maintaining a global ordering of all requests, it wouldn't be better to just require timestamps in requests that will need to be ordered. Then you only need partial orderings, which you can resolve when marging the optimistic state, only among those requests that actually need to be ordered, and requests don't need to block each other.

Edit: although now I think about it, if you go that route you effectively have to do the same timestamp ordering resolution on the server too.. so probably more complicated than just keeping a global ordering!

timestamps are rarely the answer

In my experience it is reasonable to wait in the sense that it's basically a middle layer where all the requests pass through. Also, if, as an example, there is a missing connection, you don't allow people to keep doing things. We did it on our app but you can see the same on FB app where you see a "lost connection" alert.

For timeouts etc ok, but one serverside call failure, shouldn’t hang the all application.

Reply on news.ycombinator.com