db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4563) Avoid unnecessary use of getStream and getStreamWithDescriptor
Date Thu, 25 Feb 2010 13:01:27 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristian Waagan updated DERBY-4563:

    Attachment: derby-4563-2a-replace_streamstorable_in_jdbclayer.diff

Patch 2a replaces the two occurrences of StreamStorable in the JDBC layer, using DVD.getStream()
I also observe that the use of setupContextStack() is inconsistent. In some places it is invoked
regardless of whether the value is a stream or not, in other cases a stack is pushed only
when  the value is represented by a stream.

I expect to commit this tomorrow, I'm just waiting for the regression tests to finish.

Patch ready for review.

> Avoid unnecessary use of getStream and getStreamWithDescriptor
> --------------------------------------------------------------
>                 Key: DERBY-4563
>                 URL: https://issues.apache.org/jira/browse/DERBY-4563
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions:
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For:
>         Attachments: derby-4563-1a-dvd_hasStream.diff, derby-4563-1a-dvd_hasStream.stat,
derby-4563-1b-dvd_hasStream.diff, derby-4563-2a-replace_streamstorable_in_jdbclayer.diff
> A pattern in Derby is to use the following piece of code to determine if the data value
has a stream or not:
>     if (dvd.getStream() != null) ...
> Since the stream has mutable state, obtaining a reference to it just to check if it is
not null is sub-optimal for several reasons:
>  - it may throw an exception (data types not supporting streams)
>  - the stream reference is leaked, which is unfortunately if we are / will be required
to guarantee something about the stream state (for instance that the descriptor is in sync
with the stream).
>  - in cases where we have to investigate the state of the stream, we're doing unnecessary
>  - makes it harder to write debug code (i.e., is a stream reference obtained from the
data value descriptor more than once?)
> I plan to introduce the method DataValueDescriptor.hasStream, returning a boolean.
> In addition to the obvious check if the stream variable is non-null, it can also be used
to instruct Derby to treat certain data values as non-streams even though the underlying value
is currently a stream. One example is CHAR and VARCHAR, whose maximum lengths are so small
that they should always be materialized to avoid the added complexity coming with streams
(stream state, isolation levels - extra lock to keep stream stable?, cloning).

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

View raw message