>> Then, I think the Jaybird default implementation is
>> CLOSE_CURSORS_AT_COMMIT, and all other JDBCs use
>> HOLD_CURSORS_OVER_COMMIT by default, right?
>
> Can you can prove this or this is your way of thinking?

Sorry if I sounded too rude, I meant the following (JDBC 3.0, pages 61-62):

The Connection attribute auto-commit specifies when to end transactions.
Enabling auto-commit causes the JDBC driver to do a transaction commit after
each individual SQL statement as soon as it is complete. The point at which
a statement is considered to be “complete” depends on the type of SQL
statement as well as what the application does after executing it:

- For Insert, Update, Delete, and DDL statements, the statement is complete
as soon as it has finished executing.

- For Select statements, the statement is complete when the associated
result set is closed.

The result set is closed as soon as one of the following occurs:

- all of the rows have been retrieved

- the associated Statement object is re-executed

- another Statement object is executed on the same connection

- For CallableStatement objects, the statement is complete when all of the
associated result sets have been closed.

So, as you see, there is no reference to result set holdability. Now, the
question is how should we treat the holdability and auto-commit. If we say
holdability has priority and default holdability is
HOLD_CURSORS_OVER_COMMIT, then we contradict the above statements. If we say
that auto-commit part has priority, but still keep the default holdability
to HOLD_CURSORS_OVER_COMMIT, then we are not JDBC compliant either. Jaybird
is consistent in this case - default is CLOSE_CURSORS_AT_COMMIT and comply
with auto-commit rules.

However, I would agree, if you say that my suggestion might be
non-standard - there is nothing in the specification about such situation
and I wrote only about Jaybird.

Roman