[ http://issues.apache.org/jira/browse/DERBY-1158?page=all ]
Andrew McIntyre reopened DERBY-1158:
Allow use of Statements created in local transaction with default holdability
to be used in global transactions
[ http://issues.apache.org/jira/browse/DERBY-1158?page=all ]
Andrew McIntyre closed DERBY-1158:
--
Fix Version: 10.1.3.0
Resolution: Fixed
Allow use of Statements created in local transaction with default holdability
to be used in global
default holdability of HOLD_CURSORS_OVER_COMMIT is not
restored.
--
Key: DERBY-366
URL: http://issues.apache.org/jira/browse
transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT is not
restored.
--
Key: DERBY-366
URL: http://issues.apache.org
use of Statements created in local transaction with default holdability
to be used in global transactions.
Key: DERBY-1158
URL: http://issues.apache.org/jira
Allow use of Statements created in local transaction with default holdability
to be used in global transactions.
Key: DERBY-1158
URL: http://issues.apache.org/jira
[ http://issues.apache.org/jira/browse/DERBY-1158?page=all ]
Daniel John Debrunner reassigned DERBY-1158:
Assign To: Daniel John Debrunner
Allow use of Statements created in local transaction with default holdability
to be used in global
transaction with default holdability
to be used in global transactions.
Key: DERBY-1158
URL: http://issues.apache.org/jira/browse/DERBY-1158
Project: Derby
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
HOLD_CURSORS_OVER_COMMIT.
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
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
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
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
I don't think changing default holdability is a good idea... like Dan
and Dag mentioned. Why does Derby have to change default holdability
because SUR and XA can't support it? Also Derby doesn't have SQL
cursors, only JDBC cursors, right?
Even if default is changed, SUR and XA will still
but the way I think it has to stay.
*-1* to changing the default holdability
We have to have a seamless upgrade that does not require application
changes. It is essential to the sustainability of Derby. I have said this
many times before but perhaps have not explained why, so I'll go into some
Kathey Marsden wrote:
I think ultimately if we can support loading Derby in multiple class
loaders, we document how to do that, and we get our installed user base
doing it that way be default, we will have more flexibility. For now we
don't have it. Still I would vote -1 on this one.
The
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.0.2.1
Reporter: Mamta A. Satoor
Assignee: Mamta A. Satoor
Attachments: Derby8_Derby366_061805.txt, mamta.java
A connection in local transaction has a default holdability of
HOLD_CURSORS_OVER_COMMIT. When
[ http://issues.apache.org/jira/browse/DERBY-366?page=all ]
Mamta A. Satoor closed DERBY-366:
-
In jdk13, when a connection transitions from global transaction to local
transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT
global transaction to local
transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT is not
restored.
--
Key: DERBY-366
object from XAConnection inside the global
transaction) and Derby-366 (In jdk13, when a connection transitions from global
transaction to local transaction, its default holdability of
HOLD_CURSORS_OVER_COMMIT is not restored.) The patch is attached to both
Derby-8 and Derby-366.
The fix for both
, when a connection transitions from global transaction to local
transaction, its default holdability of HOLD_CURSORS_OVER_COMMIT is not
restored
21 matches
Mail list logo