db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
Date Fri, 02 Jun 2006 18:08:18 GMT

Anurag Shekhar (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12414483 ]

> Anurag Shekhar commented on DERBY-1341:
> ---------------------------------------
> I was wrong about life time of lob. It is supposed to restricted only for the transaction
(jdbc 3.0 section 16.3.1)
For locator based that would be true.  However if it is  a copy , it 
could well live past the transaction.  This has been clarified in the 
jdbc 4 spec
> Yes its the model where DatabaseMetaData.locatorsUpdateCopy()  will return true (updates
made on a copy)
> I am following the thread and plan to be consistant with client driver's behaviour unless
its concluded other wise in that thread.
> Initially memory may be sufficient to hold the array user sets in. But user may call
setBytes multiple times resulting in a huge array which may be stored in memory. Same is true
when user is writing in the output stream.
>> LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC
>> ------------------------------------------------------------------------------------------
>>          Key: DERBY-1341
>>          URL: http://issues.apache.org/jira/browse/DERBY-1341
>>      Project: Derby
>>         Type: Bug
>>   Components: JDBC
>>     Versions:,,,,,,,,,,,,,,
>>  Environment: Windows 2000
>>     Reporter: Keith McFarlane
>>     Assignee: Anurag Shekhar
>>  JDBC LOB . getBtypes methods are not implemented in any Derby version to date: there
is a "place-holder" method that throws a SQLException reporting that the methods are not implemented.
>> It would be excellent to have any efficient Derby implementation of the getBytes
LOB methods that provide "random-access" to the binary // character content of database large
objects. The specific context is implementing a Lucene Directory interface that stores indexing
data (index files) and other binary data in a local encrypted Derby instance. 
>>  A work around is to write an encrypted RandomAccessFile implementation as a file-sdystem
buffer, perhaps writing to the database on closure. An efficient Derby implementation of LOB
. getBytes would avoid this an make for a clean design. I can think of several reasons why
random-access to LOBs would be valuable in a "hostile"  client environment. 

View raw message