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.
