db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3650) internal multiple references from different rows to a single BLOB/CLOB stream leads to various errors when second reference used.
Date Thu, 03 Jul 2008 05:24:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-3650:
----------------------------------


> I experimented a little with the patch, and was able to solve the
> problem we have when selecting the same column twice, i.e.
> "select c as c1, c as c2 from testMultipleClob"
> I did this by always creating a clone.
> I didn't quite understand what would happen to the original stream, but
> using 'finalize()' I was able to observe that it was garbage collected.
> No call to 'closeStream' was made though.
At least at store level all the streams get cleaned up at commit or abort
if at no other time.  They are all based off of open BaseContainerHandles
and all those that are open at commit or abort get cleaned up.
>
> Is it an acceptable performance hit to clone streams unconditionally for
> LOBs, or should we try to come up with some kind of bookkeeping?
> (i.e. reference counting)
> I'm thinking in the context of the JDBC layer, but the same question
> might apply to lower layers.
I am already uncomfortable with the unnecessary level of cloning/object
creation this change creates for lobs that are part of a join.  So I think
we should look to minimize it.  So I don't think it appropriate to throw in
a clone every time we see a stream.

I would like to figure out a way in a 1-1 join to not have to clone anything
and just let the original stream proprogate up.  Maybe some sort of reference
counting is the solution.
>
>
> Also, I see that a new container handle is created in 'initStream'. Am I
> correct saying that you have to do 'aClone.initStream()' after calling
> 'theStream.cloneStream()' and *before* closing 'theStream'?

I think understanding this is key to fixing this problem correctly.  After
reading the code today I think what you describe is the expected behavior,
but is not very well documented.  I think the rule currently is something
like:
    before using any Resetable interface on a stream one must call initStream().

I think there might be cleaner solutions to the various clob/blob issues if
this rule could be expanded to something like no jdbc interaction with a
blob/clob in stream form can happen unless initStream() has been called.
>
>
> The test 'tests.lang.LangScript#aggregate' failed with a NPE. The reason
> was because a null DVD was encountered and '<null>.copyForRead()' was
> called. Checking for null fixed the problem and the test succeeded.
> Can we get a null inside the for loop in 'if (! notExistsRightSide)" as
> well?
>
thanks for tracking down the bug before I could run tests.  I have fixed
the null pointer problems in the next patch.

> internal multiple references from different rows to a single BLOB/CLOB stream leads to
various errors when second reference used.
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3650
>                 URL: https://issues.apache.org/jira/browse/DERBY-3650
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.3.3.0, 10.4.1.3
>         Environment: Mac OSX 10.4
> JDK 1.5.0_13
> Hibernate EntityManager 3.2.1
>            Reporter: Golgoth 14
>            Assignee: Mike Matrigali
>         Attachments: derby-3650-preliminary_diff.txt, derby-3650_tests_diff.txt, Derby3650EmbeddedRepro.java,
Derby3650FullClientRepro.java, Derby3650FullRepro.java, Derby3650Repro.java, DerbyHibernateTest.zip,
testdb.zip, traces_on_FormatIdStream_alloc.txt, UnionAll.java
>
>
> Derby + Hibernate JPA 3.2.1 problem on entity with Blob/Clob
> Hi,
> I'm using Derby in Client - Server mode with Hibernate JPA EJB 3.0.
> When a query on an entity containing a Clob and some joins on other entites is executed,
an exception with the following message is thrown:
>   XJ073: 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 problem occurs when the property "hibernate.max_fetch_depth" is greater than 0.
> When hibernate.max_fetch_depth=0, the query works.
> If Derby is configured in embedded mode, the query works independently of the value of
hibernate.max_fetch_depth.
> On the Hibernate's documentation, the advised value of hibernate.max_fetch_depth is 3.
> Could you explain me if I made something wrong ?
> Thank you.
> Stephane

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message