Daniel John Debrunner wrote: >I've think I've found a dubious piece of code that could be the cause of >DERBY-966, holdability issues with XA connections and Derby client. >This is within the server code. > >lines 513 DRDAStatement.java > >Connection conn = database.getConnection(); >if (conn instanceof BrokeredConnection) > ps = conn.prepareStatement(sqlStmt, scrollType, concurType); >else > ps = prepareStatementJDBC3(sqlStmt, scrollType, concurType, > withHoldCursor); > > >The 'if (conn instanceof BrokeredConnection)' is dubious. > > Yes, I think you are right . Not only dubious but badly broken as evidenced by DERBY-966 . DERBY-1005, and DERBY-1006.
The wrong assumptions here (if I recall) were 1) That a BrokeredConnection meant we were in an XA transaction 2) For XA connections we could rely on the embedded server's process of switching to CLOSE_CURSORS_AT_COMMIT to avoid having such logic on the client. >I'm still looking through the code to understand how the holdability is >meant to work in jdk 13 and the network server, any pointers on that >would be helpful. > > > In general the way it works for both jdk14 and jdk13 is that the holdability is sent by the client in the PKGNAMCSN. This is parsed in parsePkgidToFindHoldability() to determine the holdability. Then statements are prepared using that value in prepareStatementJDBC3. For XA all of this is summarly ignored per the code above. Now it seems quite transparent that that is wrong, but oddly it seemed to make sense at the time. Kathey
