db-derby-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/DERBY-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609931#action_12609931
] 

Kristian Waagan commented on DERBY-3650:
----------------------------------------

Good work on the patch Mike, we need to get this bug fixed...
I applied the patch and ran the updated test.
I also ran the regression tests and got one failure (see below).
Looks to me like the general approach is working and is a feasible solution
to me.

I have the following comments on the preliminary patch, where the
whitespace and formatting only changes are mentioned because they cause
the diff to be larger than necessary:

[NestedLoopJoinResultSet]
  1) Whitespace only change.
  2) Formatting only change (first 'mergedRow ='). Intentional?
[MemByteHolder]
  3) Mix of tabs and spaces in new code.
[OverflowInputStream]
  4) SanityManager is imported, but never used.
  5) Formatting only changes.
  6) Strange indentation causing unnecessary diff (tab-space-tab):
     'columnOverflowPage.restorePortion...'
  7) Formatting only change.
[ByteHolder]
  8) Mix of tabs and spaces for indentation.
[StoredPage]
  9) Separate commit for the typo?
     File is untouched by the functional changes.
[CloneableStream]
 10) Wrong class name in header.
 11) Some tabs in the file.
[SQLChar]
 12) One tab: 'if (stream != null)'
[SQLBinary]
 13) One tab: 'if (stream != null)'
[Derby3650Test]
 14) I would prefer to remove the 'runDerby3749tests' variable after
     that bug has been fixed.
 15) Would it make sense to fill the LOBs with a pattern, instead of
     using a fixed value?
     One could use LoopingAlphabet[Stream|Reader] for this, also in the
     verification procedures (create a new stream to compare with).
     I'm thinking about detecting offset errors.
 16) Incorrect name for the setup method, which configured auto commit:
     'setup' -> 'setUp'


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.

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.


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'?


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?

I also found a small issue with LOBs related to mappings and reference
book keeping while reviewing the patch, and I'll create a Jira for that
tomorrow.

I have not yet had time to look at your questions/comments from your previous post.


> 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