db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2763) In the Network Client InputStreams and Readers returned from LOB's should be sensitive to underlying LOB data changes.
Date Wed, 13 Jun 2007 12:26:26 GMT

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

Øystein Grøvlen commented on DERBY-2763:
----------------------------------------

Rick Hillegas (JIRA) wrote:
> Thanks for the quick response, Narayanan. I think I can see how this
> patch reduces the possibility of the inconsistency which you
> describe. However, I think that there are race conditions in this
> patch which could still give rise to that inconsistency--because the
> read() methods handshake with the writers on entry and not on exit.

Thanks, for raising the issue of race conditions, Rick.  We might not
have considered that carefully enough.  One thing to note here is that
Blob/Clob objects are local to one transaction/connection.  I do not
think it is very common for two threads to share the same connection,
but we need to consider what would happen in such cases.  

In the client driver, Blob and Clob operations synchronize on the
connection, associated streams do not.  (This has not changed from
10.2).  However, in 10.3 reads and writes will lead to calls to stored
procedures, which synchronize on the connection.  Hence, only one
thread will read or write LOB fragments at a time.  However, for large
data transfers (> max VARCHAR size), reads and writes will not be
atomic.  Readers may see parts of what is written by a single API
call.  I am not sure how big a problem this is, but I think we should
consider also synchronizing on the connection in streams.

> What I'm struggling to understand is this: why are the
> inconsistencies allowed by this patch better than the
> inconsistencies allowed if we don't do anything? 

The major difference is that the inconsistencies that Narayanan is
adressing in this issue will also appear in single-threaded
environments.  That is a greater concern since multithreaded access in
the same transaction is not very likely.  

It is also quite separate issues since the multi-threaded issue should
be solved by synchronizing on the connection, while that will not
help here.  (We must also make sure that the implementation does not
introduce new multi-threaded issues.)

> What are the supported use-cases which we want to document? If I
> understood those use-cases, then I could reason about whether this
> patch actually delivers the intended benefit.

I feel that the best would be if did not have to document any
use-cases at all because the behavior is so well-defined that the
programmer by himself could imply how to behave. 
Narayanan's proposal will make it possible to say: "A read operation
on a stream will see all previous updates to a Blob/Clob object", and
I think most people would understand what that implies.

In my view, the major benefit of this patch is that you get a
well-defined behavior.  Whether that is enough value to justify the
patch, I am not 100% sure of.


> In the Network Client InputStreams and Readers returned from LOB's should be sensitive
to underlying LOB data changes.
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2763
>                 URL: https://issues.apache.org/jira/browse/DERBY-2763
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.3.0.0
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For: 10.3.0.0
>
>         Attachments: Approach_2.diff, Approach_2.stat, Approach_2.txt, Approach_3.diff,
Approach_3.stat, Approach_4.diff, Approach_4.stat, LOBLengthPersists.java, UpdateSensitiveStreamsForClient_v1.diff,
UpdateSensitiveStreamsForClient_v1.stat
>
>
> Currently the Embedded and Network Client would differ 
> in behaviour when the following series of steps is 
> followed.
> a) Create an empty Blob
> b) get an InputStream using Blob.getBinaryStream()
> c) write data into this Blob
>    c.1) Get an OutputStream
>    c.2) Use OutputStream.write(byte [] b) to write
>         into this Blob.
> d) Now read from the InputStream obtained in step b)
>    and print the number of bytes read as output.
> The output of step d) differs in the client and in the Embedded side.
> In the Client
> -------------
> The number of bytes read would always be -1.
> In the Embedded
> ---------------
> The number of bytes would be the number of bytes we
> reflected.
> The above behaviour in the NetworkClient is because
> the length of the Blob is read once and stored in the 
> constructor of the locator Stream returned (in the 
> attribute maxPos).
> This instead should be read each time we use the streams.
> A similar issue exists for Clobs also.
> I will raise a seperate JIRA issue for this.

-- 
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