db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TomohitoNakayama <tomon...@basil.ocn.ne.jp>
Subject Question around length of long column in disk page format (Re: [jira] Commented: (DERBY-782) Improvement on org.apache.derby.impl.jdbc.EmbedBlob#length())
Date Sat, 24 Dec 2005 06:04:13 GMT

I have surveyed code where length information is/may be written to disk.

Reading code around StoredPage and tracing execution with jdb,
I could not find code to write whole length information of long column 
as value in field header in disk page format.
// I read that length of information divided in pages seems to be recorded.
// But not sure why this divided length was not be seen in jdb execution 
of test programs...

I read length information of long column value is skipped to be recorded 
think this is why testLob4.java was resulted as in 

I have next questions.

Q1 :
   In the view of architecture of disk page format, is it impossible to 
record length information of long column?
   I know very little about disk page format,
   however, there seems to be no explicit description in the document 
   to conclude that it is impossible.

Q2 :
   I read that length information of long column value is skipped to be 
   However, does any other one have other information ?
   I'm not so confident ...

Best regards.

Tomohito Nakayama (JIRA) wrote:

>    [ http://issues.apache.org/jira/browse/DERBY-782?page=comments#action_12361194 ] 
>Tomohito Nakayama commented on DERBY-782:
>I have tried and found length information, which is ignored now, does not have correct
>naka@rufelza:~/derby/test/20051223$ runProgram.sh testLob4
>Initializing jdb ...
>>stop at org.apache.derby.impl.jdbc.BinaryToRawStream:94
>Deferring breakpoint org.apache.derby.impl.jdbc.BinaryToRawStream:94.
>It will be set after the class is loaded.
>run testLob4
>Set uncaught java.lang.Throwable
>Set deferred uncaught java.lang.Throwable
>VM Started: Set deferred breakpoint org.apache.derby.impl.jdbc.BinaryToRawStream:94
>Breakpoint hit: "thread=main", org.apache.derby.impl.jdbc.BinaryToRawStream.<init>(),
line=94 bci=252
>94    			int lenInBits = (((bl & 0xff) << 24) | ((v2 & 0xff) << 16)
| ((v3 & 0xff) << 8) | (v4 & 0xff));
>main[1] eval b1
>com.sun.tools.example.debug.expr.ParseException: Name unknown: b1
> b1 = null
>main[1] eval bl
> bl = 0
>main[1] eval v2
> v2 = 0
>main[1] eval v3
> v3 = 0
>main[1] eval v4
> v4 = 0
>main[1] cont
>Here goes 1st stream
>Here continue 1st stream
>The application exited
>>Improvement on org.apache.derby.impl.jdbc.EmbedBlob#length()
>>         Key: DERBY-782
>>         URL: http://issues.apache.org/jira/browse/DERBY-782
>>     Project: Derby
>>        Type: Bug
>>  Components: JDBC
>>    Reporter: Tomohito Nakayama
>> Attachments: testLob4.java
>>Now, org.apache.derby.impl.jdbc.EmbedBlob#length() method read out whole  BinaryToRawStream
to know exact length.
>>On the other hand,  BinaryToRawStream have some commented-out inplementation of having
information for length.
>>I think the information of lengh in BinaryToRawStream should be restored to be used
in .org.apache.derby.impl.jdbc.EmbedBlob#length(), because read out whole stream can be expensive
processing when streamed information was large.
>>There exists a subject that reliability of lengh information in BinaryToRawStream
is unknown.


        Tomohito Nakayama



View raw message