LOBStateTracker should not use SYSIBM.CLOBRELEASELOCATOR when the database is soft-upgraded from 10.2

• Key: DERBY-3658
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Knut Anders Hatlen
• Reporter: Knut Anders Hatlen
• Component/s: JDBC, Network Client
• Affects Version/s: 10.3.3.0, 10.4.1.3
• Fix Version/s: 10.4.2.0, 10.5.1.1

Description

Reported by Daniel Noll on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/9107

To reproduce:

  1. Create a database with Derby 10.2.2.0
  2. Create a table with a clob column and insert some data
  3. Access that database with client+server at version 10.4.1.3 and iterate through the rows in the table

You'll see an error message like this:

ERROR 42Y03: 'SYSIBM.CLOBRELEASELOCATOR' is not recognized as a function or procedure.

Comments

[Knut Anders Hatlen]

The attached patch seems to fix the problem (no regression tests have been run yet).

The problem is that the client doesn't know the version of the database accessed on the server, so a LOBStateTracker is created if the server supports locators, which does not necessarily mean that the database supports locators. The code that fetches LOBs knows how to handle this, and sets the locator to -1 if locators aren't supported. The patch therefore checks that the locator is valid before it releases it in LOBStateTracker.checkCurrentRow(). Since the locator value is invalid when locators aren't supported, this means that it won't try to call the missing stored procedures.

[Kristian Waagan]

The approach taken seems sound. +1 to commit if the tests pass.

I missed the point when I implemented this, believing if the server supported locators Cursor.locator would return a valid locator.
Does it make sense to explicitly note the possibility of an invalid locator even if the server supports it, for instance in [Net]Cursor.locator?
That said, the possibility of getting INVALID_LOCATOR should of course have made me check the value...

Thanks for looking at the patch, Kristian. The tests passed, so I committed the patch to trunk with revision 652865. I also plan to back-port it to the 10.4 branch. I'll also see if I can clarify the comments for [Net]Cursor.locator().

[Kathey Marsden]

Can you backport it to 10.3 as well?

[Kathey Marsden]

I will go ahead and merge to 10.3 and run some tests so we make the 5pm cutoff for the release.

[Knut Anders Hatlen]

Yes, I'll do that. I didn't think the bug affected 10.3, but it seems like LOBStateTracker is present on the 10.3 branch as well. Added 10.3.2.2 to the list of affected versions.

[Knut Anders Hatlen]

Merged to 10.4 with revision 652914.
Merged to 10.3 with revision 652917.

[Knut Anders Hatlen]

Ops, sorry, I missed your comment about having started back-porting it to 10.3. Some extra testing doesn't hurt though. Thanks!

[Knut Anders Hatlen]

I updated the comments in Connection.serverSupportsLocators() and Cursor.locator() so that they say explicitly that a server that supports locators may send LOB values instead of locators if the database is soft upgraded. Committed (to trunk only) revision 652929.