Databases Reference
In-Depth Information
only when the collection changes under a cursor while it is waiting to get another batch
of results.
Cursor Internals
There are two sides to a cursor: the client-facing cursor and the database cursor that
the client-side one represents. We have been talking about the client-side one up until
now, but we are going to take a brief look at what's happening on the server side.
On the server side, a cursor takes up memory and resources. Once a cursor runs out of
results or the client sends a message telling it to die, the database can free the resources
it was using. Freeing these resources lets the database use them for other things, which
is good, so we want to make sure that cursors can be freed quickly (within reason).
There are a couple of conditions that can cause the death (and subsequent cleanup) of
a cursor. First, when a cursor finishes iterating through the matching results, it will
clean itself up. Another way is that, when a cursor goes out of scope on the client side,
the drivers send the database a special message to let it know that it can kill that cursor.
Finally, even if the user hasn't iterated through all the results and the cursor is still in
scope, after 10 minutes of inactivity, a database cursor will automatically “die.”
This “death by timeout” is usually the desired behavior: very few applications expect
their users to sit around for minutes at a time waiting for results. However, sometimes
you might know that you need a cursor to last for a long time. In that case, many drivers
have implemented a function called
immortal
, or a similar mechanism, which tells the
database not to time out the cursor. If you turn off a cursor's timeout, you must iterate
through all of its results or make sure it gets closed. Otherwise, it will sit around in the
database hogging resources forever.
