[
https://issues.apache.org/jira/browse/DERBY-3749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3749:
----------------------------------
I anyone gets a chance to look at this the first thing I would track down is if
this is a bulk fetch issue. By that I mean are
N streams getting created for N rows before even the first is returned to the
user. For performance bulk fetch is the usual
way language gets rows out of the store. Then when the commit happens each
of these "open" streams gets closed.
Reading through the code I don't think these streams have any support for
holdability. Most of the hodability support is
located in the language and access layer. For instance in the case of an
access fetch loop there is code everytime the
loop is reentered to check if it is a holdable cursor and if so to reopen the
underlying resource.
My assumption is that this has been broken for many releases, but have not had
a chance to check yet.
> in holdable cursor selecting multiple rows with streaming blobs and clobs a
> commit may cause later row's streams to be broken
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3749
> URL: https://issues.apache.org/jira/browse/DERBY-3749
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.5.0.0
> Reporter: Mike Matrigali
> Priority: Minor
> Attachments: Derby3650Test.java
>
>
> In a query returning multiple rows from a table, where later rows in the
> select loop after the commit contain streaming clobs or blobs a commit may
> attempts to get at those streams after the commit to fail with a:
> 3)java.sql.SQLException: The data in this BLOB or CLOB is no longer
> available.
> The BLOB/CLOB's transaction may be committed, or its connection is closed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
