Roman Rokytskyy escreveu:

> >> 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

OK, this line is the problem with the spec... another Statement on 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.

You're right!

> 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.
>

Right too...

> 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.

I really agree with you about the consistency of Jaybird with JDBC 3.0.
But, think about this: it's very normal in systems, not only mine but
also other codes I see on Internet and developers, to use many
Statements in the same Connection, without setting up the properties
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READONLY and
ResultSet.HOLD_CURSORS_OVER_COMMIT for each one. Then, imagine all these
people changing these millions of code. I think this is a crazy way for
many of them.

Then, SUN should think about this before changing the rules of
development on each new version of specs, are you agree???