Type of ResultSet

[Ravi]

1. TYPE_FORWARD_ONLY - The result set is not scrollable; its cursor
moves forward only, from before the first row to after the last row.
The rows contained in the result set depend on how the underlying
database materializes the results. That is, it contains the rows that
satisfy the query at either the time the query is executed or as the
rows are retrieved.

2. TYPE_SCROLL_INSENSITIVE - The result set is scrollable; its cursor
can move both forward and backward relative to the current position,
and it can move to an absolute position.

3. TYPE_SCROLL_SENSITIVE - The result set is scrollable; its cursor
can move both forward and backward relative to the current position,
and it can move to an absolute position.

are the three types of the resultsets given in Java tutorial at Sun's
site. Whats the difference between the last two?

 

[Carl]

1. TYPE_FORWARD_ONLY - The result set is not scrollable; its cursor
moves forward only, from before the first row to after the last row.
The rows contained in the result set depend on how the underlying
database materializes the results. That is, it contains the rows that
satisfy the query at either the time the query is executed or as the
rows are retrieved.

2. TYPE_SCROLL_INSENSITIVE - The result set is scrollable; its cursor
can move both forward and backward relative to the current position,
and it can move to an absolute position.

3. TYPE_SCROLL_SENSITIVE - The result set is scrollable; its cursor
can move both forward and backward relative to the current position,
and it can move to an absolute position.

are the three types of the resultsets given in Java tutorial at Sun's
site. Whats the difference between the last two?

See the javadocs:

http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html#TYPE_SCROLL_INSENSITIVE

Hope that helps.
Carl.

 

[rhino]

See the javadocs:

http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html#TYPE_SCROLL_INSENSITIVE

Hope that helps.
Carl.

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.

 

[Martin Gregorie]

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.

Thats probably a property of the database's JDBC driver. It would also
depend on whether the underlying database has mechanisms that let the
driver see when changes have been made to the logical set that contains
the selected rows.