db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2379) provide encryption support for temporary files used by lob if the data base is encrypted
Date Wed, 23 May 2007 14:25:16 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498249
] 

Knut Anders Hatlen commented on DERBY-2379:
-------------------------------------------

I have looked at the v3 patch, and it looks correct to me. However,
I'm a bit worried about the performance impact this patch may have on
unencrypted data.

I would expect this to have close to zero overhead for unencrypted
lobs, but I think the patch adds some of the overhead needed for the
encrypted lobs to the unencrypted lobs as well. For instance, if we
look a call to LOBStreamControl.read(long) on an unencrypted database,
this is what happens today:

  - StorageRandomAccessFile.getFilePointer() is called to check
    whether we need to reposition with StorageRandomAccessFile.seek()

  - StorageRandomAccessFile.readByte() is called, and its return value
    is returned

With the patch, this is what happens:

  - LOBFile.getFilePointer() is called to check whether we need to
    reposition. If we need to reposition, LOBFile.seek() is called,
    which triggers these operations:

      * one call to StorageRandomAccessFile.length() to check whether
        the new position is after the end of the file

      * one call to StorageRandomAccessFile.length() to check whether
        the new position is before the end of file, in which case
        StorageRandomAccessFile.seek() is called

      * update current position pointer in LOBFile

  - LOBFile.readByte() is called, which triggers these operations:

      * one call to StorageRandomAccessFile.length() to check whether
        we try to read after the end of the file

      * one call to StorageRandomAccessFile.getFilePointer() to see
        whether we need to reposition, in which case
        StorageRandomAccessFile.seek() is called

      * one call to StorageRandomAccessFile.readByte()

      * update current position pointer in LOBFile

Similar overhead seems to have been added to all the read and write
methods, and most of it is because we maintain the current position
pointer for unencrypted lobs. I think most of the overhead could have
been avoided if LOBFile had used an OO approach with a base class for
unencrypted lobs and a sub-class for encrypted lobs.

> provide encryption support for temporary files used by lob if the data base is encrypted
> ----------------------------------------------------------------------------------------
>
>                 Key: DERBY-2379
>                 URL: https://issues.apache.org/jira/browse/DERBY-2379
>             Project: Derby
>          Issue Type: Sub-task
>          Components: JDBC
>    Affects Versions: 10.3.0.0
>         Environment: all
>            Reporter: Anurag Shekhar
>         Assigned To: Anurag Shekhar
>         Attachments: CosmeticComments_1.txt, derby-2379.diff, derby-2379v2-conflict.diff,
derby-2379v2.diff, derby-2379v3.diff
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message