4 ms·
By server-side cursors do you mean like open connections to MySQL reading a stream of query results, or something like that? I don't think that's feasible for m
by oconnor663 4y ago
By server-side cursors do you mean like open connections to MySQL reading a stream of query results, or something like that? I don't think that's feasible for most websites. The biggest issue is that you'd have to guarantee that when someone clicks "next page", their browser ends up talking to the exact same machine that it got the previous page from. But websites running on big fleets of machines don't usually work like that; instead your queries are usually somewhat randomly distributed across a whole tier. You might work around that by trying to keep a persisitent connection open from the browser to the server, but you'd lose that connection when you refreshed the page or when the server restarted, or if you lost WiFi for a minute. Making hiccups like that visible to the user is pretty frustrating. It's a lot more robust to use some sort of cursor design that doesn't rely on any persistent connections.
Some other problems that crop up:
- A lot of websites expect to serve most results from cache, and to only hit the DB a minority of the time, but to get your hands on a real DB cursor you'd have to hit the DB every time.
- Not all DB's support moving cursors backwards. Maybe most of them don't? I'm not sure.
- Open DB connections are usually a somewhat limited resource.