db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernanda Pizzorno (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-208) Add support to retrieve lobs for Network Server by locator rather than matierializing the LOB
Date Thu, 23 Nov 2006 09:19:02 GMT
    [ http://issues.apache.org/jira/browse/DERBY-208?page=comments#action_12452184 ] 
            
Fernanda Pizzorno commented on DERBY-208:
-----------------------------------------

I am investigating possible implementations LOBs using locators instead of materializing the
LOB, and I would like to suggest the following approach.

1. MOTIVATION

In the current implementation of LOBs in the Derby Client Driver, the LOBs are materialized
on the client size. In cases where large LOBS are being accesses, this materialization of
the LOBs in the client side can cause an OutOfMemoryError.

2. APPROACH

The network client will request LOB columns to be sent as LOB Locators instead of data value
bytes. Since the client no longer has a copy of the LOB data value bytes, operations on the
LOB data will be performed on the server side, and the results of these operations will be
sent to the client. The client will request the execution of an operation by the server by
calling a stored procedure.

2.1 DRDA

The Output Override Descriptor (OUTOVR) allows the client to specify the output format for
data to be returned as output to an SQL statement or query. This command data object must
be sent with the command that returns the LOB data column as output (either a CNTQRY - Continue
Query, or an EXCSQLSTT Execute SQL Statement commands). LOB columns are returned by default
as data value bytes, in order to receive the LOB columns as LOB Locators, the network client
must explicitly request it using the OUTOVR command data object.

2.2 JDBC Driver

The implementation of LOB related JDBC methods in the network client must be converted to
use LOB Locators instead of having a copy of the LOB data in the client side. Since the client
will no longer have the data value bytes for the LOB, operations performed on the data must
be performed on the server side. This will be done using stored procedures. Each time a LOB
related JDBC method is called, the client driver will "convert" that call into a call to one
or more stored procedures. These are the necessary stored procedure to implement LOB related
JDBC methods:

 * CreateLocator(LocatorType IN SMALLINT, Locator OUT INTEGER)
        -> Allocates a new LOB in a temporary space and returns its Locator
 * ReleaseLocator(LocatorType IN SMALLINT, Locator IN INTEGER)
        -> Releases a LOB.
 * GetPosition(LocatorType IN SMALLINT, Locator IN INTEGER, 
               SearchLocator IN INTEGER, SearchLiteral IN STRING, 
               FromPosition IN INTEGER, LocatedAt OUT INTEGER)
        -> Returns the position in bytes/characters of the first occurrence of 
           SearchLocator or SearchLiteral within the LOB.
 * GetLength(LocatorType IN SMALLINT, SourceLocator IN INTEGER, 
             Length OUT INTEGER) 
        -> Returns the length in bytes/characters of the LOB
 * GetSubString(LocatorType IN SMALLINT, SourceLocator IN INTEGER, 
                FromPosition IN INTEGER, ForLength IN INTEGER, 
                String OUT STRING)
        -> Returns a byte array or string containing the bytes/characters 
           starting at FromPosition and with length ForLength
 * SetString(LocatorType IN SMALLINT, SourceLocator IN INTEGER, 
             FromPosition IN INTEGER, ForLength IN INTEGER, 
             String IN STRING)
        -> Replaces the bytes/characters at position FromPosition with 
           ForLength bytes/characters from String	
 * Truncate(LocatorType IN SMALLINT, SourceLocator IN INTEGER, 
            Length IN INTEGER)
        -> Truncates the LOB to Length

3. COMPATIBILITY

3.1 Old server with new client

The new network client will always request to receive the LOB columns as LOB Locator values
instead of the data values bytes. This request is done by sending an OUTOVR object describing
the desired type with the CNTQRY command. The current implementation of the network server
is able to parse these OUTOVR objects so receiving such an object from the client will not
cause an error to happen. However, the network server does not do anything with the information
received in the OUTOVR object, so it will continue to send the LOB columns as data value bytes
instead of sending the LOB Locator.

In order to preserve compatibility between the current network server and a new network client,
the new network client must be able to handle LOB data value bytes.

3.2 Old client with new server

The new server will be able to send LOB columns as LOB Locators instead of sending them as
LOB data values bytes, if the network client requests it. The behavior of the old client is
unchanged, so it will continue to request for the LOB columns to be sent as LOB data value
bytes.

In order to preserve compatibility between the current network client and a new network server,
the new network server must be able to return LOB columns both as LOB Locators and as LOB
data values bytes. If the client request the LOB columns to be sent as LOB Locators, the server
will return them as LOB Locators, otherwise it will return them as LOB data value bytes. This
should also preserve the compatibility with the JCC client.


> Add support to retrieve lobs for Network Server by locator rather than matierializing
the LOB
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-208
>                 URL: http://issues.apache.org/jira/browse/DERBY-208
>             Project: Derby
>          Issue Type: New Feature
>          Components: Network Server
>    Affects Versions: 10.1.1.0
>            Reporter: Kathey Marsden
>
> Currently Network Server materializes all LOB objects.  LOB locator support is part of
the DRDA spec so could be added to network server.  See
> http://www.opengroup.org/dbiop/
> It is not clear if SQL Support for LOB locators would also be required.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message