In other words, a "sensitive" result set will (usually) notice changes made
to the rows in the original database table after you have built the initial
result set and make them available to you.

For example, let's say your result set contains all blue Fords registered in
the state of New York in 2007 and you create the result set at exactly 2 PM.
And let's say that you are using a GUI program and the user goes on a 15
minute coffee break just after creating the result set. Then, the user comes
back and starts scrolling through the list of blue Fords. If the result set
is sensitive, it _should_ be updated by Java to include all blue Fords
registered between 2 PM and the current time. Therefore, you will see cars
that have been registered since the result set was built. Also, let's say
that some of those blue Fords were mis-registered and they were actually
brown Fords (or blue Hondas) and someone had corrected those records between
2 PM and 2:15 PM; a sensitive result set should also reflect that some of
the cars which were believed to be blue Fords at 2 PM are actually not so
that those cars should be removed from the result set.

The disturbing thing (for me) is the word "generally" in the descriptions of
"sensitive" and "insensitive". Apparently, we cannot be absolutely sure that
all updates and deletes made to original row will be reflected in the
sensitive result set. That raises the obvious question of when we can count
on those changes being accurate and when they won't be.

--
Rhino