3 ms·
Requests should be kept alive. For any system, if the requester goes away, eventually the system should stop doing work on their behalf. That seems like the roo
by asdfasgasdgasdg 6y ago
Requests should be kept alive. For any system, if the requester goes away, eventually the system should stop doing work on their behalf. That seems like the root of the problem in the situation you're describing.
- deathanatos 6y agoYes, I'd agree, but a fair number of database's wire protocols have no means of saying "this request is cancelled"! As for "if the requester goes away", remember that the requester might be a few hops away. E.g., the HTTP connection from the mobile client drops; the web server and its connection to the DB is still alive and well. I can forcefully shut that connection, but that's somewhat of a drag (I'd rather keep it open, since it is perfectly good). Beyond closing the connection, and being able to issue some form of "cancel this query" request: HTTP/1 lacks it entirely, PostgreSQL requires opening a separate connection, Redis lacks it entirely, and I think both Mongo and MySQL lack it entirely. Even support for "time this request out" is spotty.
- toast0 6y ago> PostgreSQL requires opening a separate connection, Redis lacks it entirely, and I think both Mongo and MySQL lack it entirely. MySQL has a kill command, which does need to be done on another connection (might also need more permissions, it's been a while). It's been a while since I used a lot of MySQL, but this was definitely a pain point when things went sideways.
- jd_mongodb 6y agoMongoDB has killOp which will allow a user to kill any operation they have an operation ID for: https://docs.mongodb.com/manual/reference/method/db.killOp/ https://docs.mongodb.com/manual/reference/method/db.killOp/