I agree with Bernt that I find it surprising that users depend
on resultsets being holdable, but my experience is that there
are many applications out there where this is the case. I am
not going to try to argue what is right (personally I cringe at
what kind of consistency those clients are really expecting from
an updatable holdable cursor across a commit).
But I will add that I can verify what Dan said. Historically
Cloudscape did not have holdable cursors, it was added later. When
it was added we were pushed by a number of applications to make it
the default as when those apps were ported from other db's that is
what they expected. While I agree it is not a big deal for someone
writing an app to set the holdability flag, there are a number of
third parties who don't have access to the source who just want to
run their app unchanged on this jdbc driver.
Bernt M. Johnsen wrote:
Hi all,
Allthough I agree that backwards compatability is important, I find
the current default unfortunate for several reasons:
1) As Anreas points out: The architecture seems to be designed for
non-holdable cursors (in agreement with the old Cloudscape
default).
2) Cursors in the SQL standard defaults to non-holdable
3) It does not fit very well with global transactions
And I am not convinced that very many exsisting apps depend on
resultsets being holdable without being explicit in the JDBC calls.
Dag H. Wanvik wrote (2006-02-22 18:09:04):
Hi,
Daniel John Debrunner <[EMAIL PROTECTED]> writes:
The JDBC 3.0 spec is silent on this, sections 14.1.1 and 14.1.2 describe
what can be done when a ResultSet type or concurrency is not supported.
However in 14.1.3 there is no comment about what can be done when a
requested holdability is not supported. Also ResultSet does not have a
getHoldability method to allow the application to determine if its
request was honoured or not.
I just can't see the value in changing the default behaviour and
affecting existing applications because holdability is not supported in
two cases.
I agree with Dan on this one. Rather than risk breaking existing apps,
for SUR, we should just document this for now; hopefully we can find a
solution for holdable SUR also, along the lines Mike outlined (by
invalidating open result sets when inline compress happens), so the
restriction can be lifted.
Thanks,
Dag
I seem to remember that most users assumed Cloudscape in the past
supported holdable results sets and expected it to be the default. They
were suprised when it didn't.
Dan.
--
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
