db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: default holdability
Date Fri, 24 Feb 2006 22:33:03 GMT
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):
>>Daniel John Debrunner <djd@apache.org> 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.
>>>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.
>>Dag H. Wanvik
>>Sun Microsystems, Database Technology Group (DBTG)
>>Haakon VII gt. 7b, N-7485 Trondheim, Norway
>>Tel: x43496/+47 73842196, Fax:  +47 73842101

View raw message