Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Thu, 19 Jul 2007 23:24:36 +0200
From: =?ISO-8859-1?Q?=D8ystein_Gr=F8vlen?= <Oystein.Grovlen@Sun.COM>
Subject: DERBY-2892 comment
Sender: Oystein.Grovlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <469FD694.4060607@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)

Seems like my comment on DERBY-2892 was not sent to the list.  (JIRA was 
having trouble when I made it).  I am reposting it here:

I think I would prefer that one did not use database locks to
achieving stability for LOB objects. Locks are intended for
transaction isolation, not result set isolation. I guess the main
motivation for using locking is to avoid reading the entire LOB before
it is accessed. That is, when ResultSet.getBlob is called the Blob
value is not read; the reading is delayed until one performs
operations on that Blob. Pre-10.3, one major problem with making a
copy of a LOB would be that the entire LOB would have to be stored in
main-memory. In 10.3, we have a mechanism for storing LOB values
temporarily on disk.

One alternative would be to always make a copy when getBlob/getClob is
called. That could significantly affect the performance of such an
operation, but users can use ResultSet.getBinaryStream if they want
to read a Blob with less overhead.

A more performant solution would be to delay copying until it is
needed. That is, when someone else tries to update the LOB, a copy is
made. I think such conflicts are not very typically for databases
with LOBs, so copying will normally not be done very often. However,
one need some mechanism for detecting that the LOB to be updated are
currently read by others.

I am trying to get my mind around what is required here. I do not
have a full undestanding yet, but here are some aspects that need to
be considered:

  - When locators are used, a locator will map to an Blob/Clob object
    on the server. Client operations will be mapped to operations on
    the Blob/Clob objects. This makes the current locking mechanism
    not work as intended since you will get Blob/Clob objects without
    doing explicit getBlob/getClob calls.

  - The server is not able to distinguish whether an operation is
    performed on a Blob/Clob or directly on the ResultSet. E.g.,
    Blob.getBinaryStream and ResultSet.getBinaryStream are local
    operations on the client. Read operations on the streams will map
    to Blob.getBytes on the server.

  - Locators are not used for all types of client operations. E.g.,
    ResultSet.updateBinaryStream or PreparedStatement.setBinaryStream
    will set up a stream that maps to a stream on the server.

  - Updates to Blob/Clob objects will cause the object to be copied to
    temporary storage. The updates will be applied to the database
    when the Blob/Clob object is used to update a row. E.g., If
    ResultSet.updateBlob is used, the update will happen when
    ResultSet.updateRow is called. If PrepareStatement.setBlob is used,
    it will happen when the prepared statement is executeed.

  - We will still need a mechanism to protect LOB values of the current
    row of a ResultSet from being updated. I am not familiar with the
    current mechanism here.