db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mayuresh Nirhali (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-595) Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
Date Thu, 08 Mar 2007 06:03:24 GMT

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

Mayuresh Nirhali commented on DERBY-595:
----------------------------------------

After some debugging, I found that the call to getString returns the Exception as a String
and, more importantly, leaves the DVD in inconsistent state. Here is why.

The logging code calls the getTraceString to identify the data length. In case of Streams,
such objects are fully read when getString is called populating a DVD object. So, after the
statement logging is done, the object is treated as DVD itself and not a stream, So the expected
exception would not occur. 
Now, currently In the current statement logging code, the exception is returned as a String
so it is thrown properly to the user.

For the specific case of input stream having too few bytes (less bytes actually on stream
than expected), the DVD that is populated is not in consistent state. This is because the
java.io.DataInputStream will read until input data is available, end of file is detected,
or an exception occurs. As the bytes available are fewer than expected the DIStream will believe
that there are some more bytes to be read even after reading the available bytes. This next
read call returns -1 and puts the DVD in invalid state.

So, eating up the Exception in the logging code does not seem to work.

Only 2 options come to my mind, at this point.

1. Handle the Exception properly in the statement logging code, so that any errors in the
stream object will be properly notified to the user.
2. Defer full read of stream until statement logging is complete. During statement logging
only provide expected length of the stream. This behavior will be exactly same as the behavior
when logStatementText is FALSE in terms of when the stream is fully read.

I would appreciate experts' opinion here... and please let me know if there is any other way
this bug can be fixed.

TIA
Mayuresh

> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect
behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-595
>                 URL: https://issues.apache.org/jira/browse/DERBY-595
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
>         Environment: all
>            Reporter: Sunitha Kambhampati
>         Assigned To: Mayuresh Nirhali
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect
behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised
when DVD.getString() is called, the exception gets eaten up when this property is set. 
> See 
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction:   Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true
and  expected error exceptions wont be thrown for the error cases.  
> I looked at the tests that use streams , only the store/streamingColumn.java  uses derby.language.logStatementText=true.
I'll file another bug to resolve this test.

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