4 ms·

We have attempted to use sendBeacon as a last resort signal for releasing an exclusive lock granted to a user for editing a record. Only one user can be granted

We have attempted to use sendBeacon as a last resort signal for releasing an exclusive lock granted to a user for editing a record. Only one user can be granted this at a time for a given record to avoid contention, but there are so many ways a user might abandon an edit-in-progress in web applications (close browser, inactivity, loss of network or power). I realize there are a lot of different strategies for addressing this situation, and I'd be curious to hear how others have solved this problem. In the specific case of using sendBeacon, it is a little disheartening that once a basic programming tool gets abused by the analytics/advertising/tracking behemoths then the ad blockers' only recourse at times is to disable it completely. I completely support the efforts made by the ad blockers, but also find it sad how legitimate uses of certain tools end up getting blocked in the process.

Resonance1584 4y ago
I'd just open a websocket and send regular ping messages, release the lock on disconnect
flatline 4y ago
The industry has, for the most part, been migrating to live collaborative edits via CRDTs and the like rather than exclusive access with non-deterministic terminating conditions. You could argue that the whole field of distributed computing is geared toward solving this type of problem.
scottlamb 4y ago
My first preference would be to avoid it by using optimistic concurrency control rather than locking. Maybe display a hint that someone else is editing but allow the user to ignore it.
thomastay 4y ago
As others have mentioned, this is very well studied in the field of distributed computing, where servers can acquire a lock and then immediately disconnect due to a power failure. Other people have recommended CRDTs and Optimistic Concurrency control, which is great if you are designing an app from the ground up. If you have an existing large app that just needs locks, though, I recommend following the Chubby paper: https://research.google.com/archive/chubby-osdi06.pdf https://research.google.com/archive/chubby-osdi06.pdf Section 2.4 Locks addresses how Chubby thinks about locking in a distributed system: It is costly to introduce sequence numbers into all the interactions in an existing complex system. Instead, Chubby provides a means by which sequence numbers can be introduced into only those interactions that make use of locks. At any time, a lock holder may request a sequencer, an opaque byte-string that describes the state of the lock immediately after acquisition. It contains the name of the lock, the mode in which it was acquired (exclusive or shared), and the lock generation number. The client passes the sequencer to servers (such as file servers) if it expects the operation to be protected by the lock. The recipient server is expected to test whether the sequencer is still valid and has the appropriate mode; if not, it should reject the request. The validity of a sequencer can be checked against the server’s Chubby cache or, if the server does not wish to maintain a session with Chubby, against the most recent sequencer that the server has observed. The sequencer mechanism requires only the addition of a string to affected messages, and is easily explained to our developers. Although we find sequencers simple to use, important protocols evolve slowly. Chubby therefore provides an imperfect but easier mechanism to reduce the risk of delayed or re-ordered requests to servers that do not sup- port sequencers. If a client releases a lock in the normal way, it is immediately available for other clients to claim, as one would expect. However, if a lock becomes free because the holder has failed or become inaccessible, the lock server will prevent other clients from claiming the lock for a period called the lock-delay. Clients may specify any lock-delay up to some bound, currently one minute; this limit prevents a faulty client from making a lock (and thus some resource) unavailable for an arbitrarily long time. While imperfect, the lock-delay protects unmodified servers and clients from everyday problems caused by message delays and restarts
kbenson 4y ago
If you haven't accounted for the fact that there is absolutely no way to guarantee the client has just disappeared, all you've don't is build a system on bad assumptions. A client browser can crash, the computer can lose power, the network can be unplugged, the router can crash, the internet connection can go down. It doesn't matter why, there are many common reasons why you can't rely on an unlock signal, so must be able to deal with that situation. If you realize that from the beginning and design accordingly, it's usually easier to handle than realizing it later and trying to add special cases to catch it later. For example, if you know the above is a problem, you might just opt to make a lock for a record the I'd of the locking user and the last lock update time, and update the lock every few seconds during normal operation when locked. If there's a problem, that user can pick up the lock without problem when reconnecting, but if any other user attempts to lock the record and the lock hasn't been updated in a minute or two, then consider it invalid and let the new user lock. Anyone attempting to edit a record with a lock that isn't too old is told it's actively locked and to try back in a few minutes. All of a sudden your lock release problems are automatically cleaned up by normal use, can be easiest found as needed by searching for old timestamps, and the person that has to deal with problems is the person with the behavior/system causing the problem. There are obviously more complicated (and for some cases better) solutions, but the takeaway is to look at the problem and constraints as a whole and find a solution with the right trade offs given your needs, and not let the constant accretion of small features lead you to a suboptimal solution what doesn't work.

Resonance1584 4y ago

I'd just open a websocket and send regular ping messages, release the lock on disconnect

flatline 4y ago

The industry has, for the most part, been migrating to live collaborative edits via CRDTs and the like rather than exclusive access with non-deterministic terminating conditions. You could argue that the whole field of distributed computing is geared toward solving this type of problem.

scottlamb 4y ago

My first preference would be to avoid it by using optimistic concurrency control rather than locking. Maybe display a hint that someone else is editing but allow the user to ignore it.

thomastay 4y ago

As others have mentioned, this is very well studied in the field of distributed computing, where servers can acquire a lock and then immediately disconnect due to a power failure. Other people have recommended CRDTs and Optimistic Concurrency control, which is great if you are designing an app from the ground up. If you have an existing large app that just needs locks, though, I recommend following the Chubby paper: https://research.google.com/archive/chubby-osdi06.pdf https://research.google.com/archive/chubby-osdi06.pdf Section 2.4 Locks addresses how Chubby thinks about locking in a distributed system: It is costly to introduce sequence numbers into all the interactions in an existing complex system. Instead, Chubby provides a means by which sequence numbers can be introduced into only those interactions that make use of locks. At any time, a lock holder may request a sequencer, an opaque byte-string that describes the state of the lock immediately after acquisition. It contains the name of the lock, the mode in which it was acquired (exclusive or shared), and the lock generation number. The client passes the sequencer to servers (such as file servers) if it expects the operation to be protected by the lock. The recipient server is expected to test whether the sequencer is still valid and has the appropriate mode; if not, it should reject the request. The validity of a sequencer can be checked against the server’s Chubby cache or, if the server does not wish to maintain a session with Chubby, against the most recent sequencer that the server has observed. The sequencer mechanism requires only the addition of a string to affected messages, and is easily explained to our developers. Although we find sequencers simple to use, important protocols evolve slowly. Chubby therefore provides an imperfect but easier mechanism to reduce the risk of delayed or re-ordered requests to servers that do not sup- port sequencers. If a client releases a lock in the normal way, it is immediately available for other clients to claim, as one would expect. However, if a lock becomes free because the holder has failed or become inaccessible, the lock server will prevent other clients from claiming the lock for a period called the lock-delay. Clients may specify any lock-delay up to some bound, currently one minute; this limit prevents a faulty client from making a lock (and thus some resource) unavailable for an arbitrarily long time. While imperfect, the lock-delay protects unmodified servers and clients from everyday problems caused by message delays and restarts

kbenson 4y ago

If you haven't accounted for the fact that there is absolutely no way to guarantee the client has just disappeared, all you've don't is build a system on bad assumptions. A client browser can crash, the computer can lose power, the network can be unplugged, the router can crash, the internet connection can go down. It doesn't matter why, there are many common reasons why you can't rely on an unlock signal, so must be able to deal with that situation. If you realize that from the beginning and design accordingly, it's usually easier to handle than realizing it later and trying to add special cases to catch it later. For example, if you know the above is a problem, you might just opt to make a lock for a record the I'd of the locking user and the last lock update time, and update the lock every few seconds during normal operation when locked. If there's a problem, that user can pick up the lock without problem when reconnecting, but if any other user attempts to lock the record and the lock hasn't been updated in a minute or two, then consider it invalid and let the new user lock. Anyone attempting to edit a record with a lock that isn't too old is told it's actively locked and to try back in a few minutes. All of a sudden your lock release problems are automatically cleaned up by normal use, can be easiest found as needed by searching for old timestamps, and the person that has to deal with problems is the person with the behavior/system causing the problem. There are obviously more complicated (and for some cases better) solutions, but the takeaway is to look at the problem and constraints as a whole and find a solution with the right trade offs given your needs, and not let the constant accretion of small features lead you to a suboptimal solution what doesn't work.