db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Lifetime of Blob/Clob objects, compatibility issues
Date Fri, 13 Apr 2007 19:50:19 GMT
Oystein Grovlen - Sun Norway wrote:
> 
> As part of the work on using locators for Blob/Clob, we will need to
> be able to determine when to garbage collect information about locators.
> The JDBC spec says the following about lifetime of Blobs [JDBC 4 spec,
> section 16.3.1]:
> 
>     For locator based implementations, Blob, Clob and NClob objects
>     remain valid for at least the duration of the transaction in which
>     they are created, unless their free method is invoked or they are
>     garbage collected.
> 
>     For implementations that fully materialize the Large Object (LOB),
>     the Blob, Clob and NClob objects will remain valid until such time
>     as the free method is called or the LOB is garbage collected.
> 
>     Portable applications should not depend upon the LOB persisting
>     past the end of the transaction.
> 
> Note that the current Derby behavior diverges from this spec in
> several aspects,

How does Derby diverge from the spec (quoted above)?

> and I would say the current behavior is quite a mess.
> Some observations I have made:
> 
>    - In embedded, objects for short LOB values are valid after
>      transaction commit, objects for long values are not.  The same
>      holds after the connection is closed.
seems to be within spec (lob is fully materialized)

>    - On the client, objects are generally valid after commit.
seems to be within spec (lob is fully materialized?)

>    - On the client, length() may be called on Clob objects after the
>      connection is closed.  However, other methods are not allowed.
>    - On the client, no operations can be performed on a Blob after
>      connection is closed.
seems inconsistent and against the spec if lobs are fully materialized 
but within the spec if the lobs are locator based.

> In my opinion, we should strive to get the same behavior regardless
> of framework or LOB size.  The plan is to change the lifetime of LOB
> objects to correspond to the lifetime of the transaction in which it
> was created.  A life beyond the close of the connection, is not
> possible on the client side, and an implementation where LOB objects
> are valid after commit will be pretty complex, both generally on the
> client side and for large LOBs in embedded.

For 10.3 are client LOB's locator based and embedded non-locator based?

In 10.2 client LOB's are fully materialized, right?

> Changing the lifetime for Blob/Clob objects, may cause compatibility
> issues for existing applications.  Client applications that currently
> access LOB objects after commit, and embedded applications that access
> small LOB objects after commit, will have to be changed.  Do people
> think this is acceptable?

I guess I'm unclear at this point, how much of the behaviour will be 
changing due to the switch to locator LOB's and how much to due cleanup. 
Is it possible to have a summary of behaviour compared to 10.2?

Thanks,
Dan.



Mime
View raw message