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) Derby + Hibernate JPA 3.2.1 problem on entity with Blob/Clob
Date Wed, 14 May 2008 22:05:55 GMT

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

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


I am not sure of the solution, but thought I would share my understanding
of the stream and clob datatype support from store up through language
on the embedded side of the system - hoping to spark a discussion.
The more of these bugs that come up
makes me think that a number of things are working by accident and that
we just keep patching up the latest thing that crops up which then pushes
something else up later.  The main area of concern are cases where we
copy and or share references to a single column that may contain a stream.

For this discussion I am going to concentrate on an embedded client not
using locators.

The base use case is that language requests a column from store, which
reads the data into a datatype.  In this case the datatype of interest
is SQLClob, but the discussion is similar internally to all the types
that could support a stream representation (SQLChar, SQLVarchar, SQLClob,
SQLBlob, ...).  All these datatypes, internal to the datatype, can either
hold the data completely in memory at the point of exit from the store
routines or in the form of a stream which can be held unread until finally
getting to user.

The initial decision of whether the state should be a stream or in memory
is first decided by the store layer.  Basically if the entire column data
resides on one page then the data is read into an array.  If the column
spans multiple pages then a stream is returned which knows how to traverse
the pages of the store to return the stream.  Subsequently the datatype
itself can decide to materialize the stream into memory, but code avoids this
as it may mean instantiating a 2GB blob in memory.

The functionality of the stream is somewhat limited.  It is assumed single
user and can only be read from front to back.  It does support a reset
functionality which can rewind the stream back to the beginning.  The
stream keeps a buffer of the current page worth of data that has been
read.

A number of issues stem from the system copying
references to streams rather than somehow making independent copies of
the streams.  For instance:
DERBY-3650 - during a 1 to many join, multiple rows end up with references to
             a single stream.
DERBY-3646 - select of same clob twice in row leads to 2 references to same
             column.


o If we want to continue the current usage then how are we going to manage
  multiple references to a single stream across rows?  The new free code
  adds problems here.  We have defined a lot of the other problems away
  with documenting we don't support stream references across rows.
o If we want to continue the current usage of sharing reference across columns
  what kind of concurrent stream access should we support (see the list of
  options in 3646)


I don't know how hard it is but should we just stop language from sharing
references to streams?  The existing usage works very well for all the other
datatypes including the stream types when they are not streams.

Should we somehow make the datatype/stream smarter to somehow handle the
multiple reference?

Should we recognize the multiple reference and just give up and materialize
the clob?

> Derby + Hibernate JPA 3.2.1 problem on entity with Blob/Clob
> ------------------------------------------------------------
>
>                 Key: DERBY-3650
>                 URL: https://issues.apache.org/jira/browse/DERBY-3650
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.3.2.2, 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
>         Attachments: Derby3650EmbeddedRepro.java, Derby3650FullClientRepro.java, Derby3650FullRepro.java,
Derby3650Repro.java, DerbyHibernateTest.zip, testdb.zip, traces_on_FormatIdStream_alloc.txt,
UnionAll.java
>
>
> 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