db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: default holdability
Date Wed, 22 Feb 2006 16:58:03 GMT
Andreas Korneliussen wrote:

> Currently Derby supports a limited combination of ResultSet types and
> Resultset concurrency modes. Common for all the current combinations, is
> that Derby can support HOLD_CURSORS_OVER_COMMIT, however for future
> combinations this may be a problem.
> 
> We have a problem in that Derby may not be architected to correctly
> implement "holdable" scrollable updatable resultsets (SUR), and as a
> fallback, we may consider not to support the holdabilitiy for SUR.
> 
> I also saw some JIRAs with synopsis:
> 
> Derby-1005: "Holdability for a connection should automatically become
> CLOSE_CURSORS_AT_COMMIT for a global transaction."
> 
> and
> 
> Derby-1006:"Client allows setHoldability to HOLD_CURSORS_OVER_COMMIT  on
> both connection and statement in a global transaction "
> 
> I am not sure these are relevant for the discussion, however it seems to
> me that there are other places in the system where Derby cannot support
> HOLD_CURSORS_OVER_COMMIT.

I think before any SUR changes the only place where holdability is not
supported is within global (XA) transactions.

If the initial implementation of SUR doesn't support holdable result
sets then I think that's a great first step.

> I think Derby is architected to support the holdability mode
> CLOSE_CURSOR_AT_COMMIT by all combinations of ResultSets.
> 
> I therefore find it reasonable to consider changing the *default*
> holdability mode from HOLD_CURSORS_OVER_COMMIT to CLOSE_CURSORS_AT_COMMIT.

This is of course a incompatible change for existing applications, and
has the potential to break them.

> Clients which depend on HOLD_CURSOR_OVER_COMMIT, should as a consequence
> explictly set the holdability. I think that a client should not depend
> on holdability mode without specifying it from the application, or at
> least check the DatabaseMetadata.getDefaultHoldability() and then call
> setHoldability() on the Connection it if it depends on something else.
> If Derby cannot support the specified holdability for a specific
> resultset type, Derby could downgrade the holdabiltiy, and give a warning.

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


Mime
View raw message