Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <5601546.1178489355333.JavaMail.jira@brutus>
Date: Sun, 6 May 2007 15:09:15 -0700 (PDT)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2111) EOFException when using stream as
 parameter for multi-row update statement in embedded driver
In-Reply-To: <18704239.1164273962039.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/DERBY-2111?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-2111:
----------------------------------

    Component/s: SQL

Any fix should preserve the current performance for a single row update (ie=
. it should only read the stream once and use it to directly update store).=
  I don't know how hard it is to recognize ahead of  doing the 1st update t=
hat a second update may be necessary.  The=20
actual value assuming the stream has been used to update a column is availa=
ble from the table and could be read back from=20
the store for subsequent updates - if anyone thinks this is necessary. =20

Anyone know what other db's do with streams too big for memory in this case=
?

> EOFException when using stream as parameter for multi-row update statemen=
t in embedded driver
> -------------------------------------------------------------------------=
--------------------
>
>                 Key: DERBY-2111
>                 URL: https://issues.apache.org/jira/browse/DERBY-2111
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.2.1.6, 10.3.0.0
>         Environment: Embedded JDBC driver
>            Reporter: =C3=98ystein Gr=C3=B8vlen
>            Priority: Minor
>         Attachments: streamtest.java
>
>
> If a stream is used as parameter to an update statement that will update =
several rows, the update statement will fail.
> I will attach a JUNIT test that reproduces this error.  This only fails w=
ith the embedded driver.  It works well with the client driver.  The except=
ion I get is:
> There was 1 error:
> 1) testMultipleUpdates(org.apache.derbyTesting.functionTests.tests.jdbcap=
i.streamtest)ERROR XSDA4: An unexpected exception was thrown
>        at org.apache.derby.iapi.error.StandardException.newException(Stan=
dardException.java:298)
>        at org.apache.derby.impl.store.raw.data.UpdateOperation.<init>(Upd=
ateOperation.java:110)
>         at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpd=
ate(LoggableActions.java:80)
>    at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(Stor=
edPage.java:8537)
>  at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.j=
ava:1111)
>        at org.apache.derby.impl.store.access.conglomerate.GenericConglome=
rateController.replace(GenericConglomerateController.java:479)
>         at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(Row=
ChangerImpl.java:523)
>   at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRow=
s(UpdateResultSet.java:579)
>       at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateRes=
ultSet.java:273)
>      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Generi=
cPreparedStatement.java:358)
>         at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Emb=
edStatement.java:1182)
>  at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Em=
bedPreparedStatement.java:1635)
>  at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Embed=
PreparedStatement.java:299)
>      at org.apache.derbyTesting.functionTests.tests.jdbcapi.streamtest.te=
stMultipleUpdates(streamtest.java:83)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl=
.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth=
odAccessorImpl.java:25)
>         at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCas=
e.java:76)
>      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>       at junit.extensions.TestSetup.run(TestSetup.java:23)
> The underlying error is:
> .java.io.EOFException: Stream has already been read and end-of-file reach=
ed and cannot be re-used.
>   at org.apache.derby.iapi.types.ReaderToUTF8Stream.read(ReaderToUTF8Stre=
am.java:185)
>      at org.apache.derby.impl.store.raw.data.MemByteHolder.write(MemByteH=
older.java:146)
>      at org.apache.derby.impl.store.raw.data.RememberBytesInputStream.fil=
lBuf(RememberBytesInputStream.java:135)
>      at org.apache.derby.impl.store.raw.data.StoredPage.logColumn(StoredP=
age.java:6155)
>       at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPag=
e.java:3959)
>  at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDat=
aToBuffer(UpdateOperation.java:255)
>      at org.apache.derby.impl.store.raw.data.UpdateOperation.<init>(Updat=
eOperation.java:106)
>         at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpd=
ate(LoggableActions.java:80)
>    at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(Stor=
edPage.java:8537)
>  at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.j=
ava:1111)
>        at org.apache.derby.impl.store.access.conglomerate.GenericConglome=
rateController.replace(GenericConglomerateController.java:479)
>         at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(Row=
ChangerImpl.java:523)
>   at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRow=
s(UpdateResultSet.java:579)
>       at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateRes=
ultSet.java:273)
>      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Generi=
cPreparedStatement.java:358)
>         at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Emb=
edStatement.java:1182)
>  at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Em=
bedPreparedStatement.java:1635)
>  at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Embed=
PreparedStatement.java:299)
>      at org.apache.derbyTesting.functionTests.tests.jdbcapi.streamtest.te=
stMultipleUpdates(streamtest.java:83)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl=
.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth=
odAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>      at junit.framework.TestCase.runTest(TestCase.java:154)
>   at junit.framework.TestCase.runBare(TestCase.java:127)
>   at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java=
:76)
>      at junit.framework.TestResult$1.protect(TestResult.java:106)
>     at junit.framework.TestResult.runProtected(TestResult.java:124)
>  at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>       at junit.framework.TestSuite.runTest(TestSuite.java:208)
>         at junit.framework.TestSuite.run(TestSuite.java:203)
>     at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>       at junit.framework.TestResult.runProtected(TestResult.java:124)
>  at junit.extensions.TestSetup.run(TestSetup.java:23)
>     at junit.framework.TestSuite.runTest(TestSuite.java:208)
>         at junit.framework.TestSuite.run(TestSuite.java:203)
>     at junit.textui.TestRunner.doRun(TestRunner.java:116)
>    at junit.textui.TestRunner.start(TestRunner.java:172)
>    at junit.textui.TestRunner.main(TestRunner.java:138)
> I assume this indicates that the stream is used directly to update a row,=
 and that it fails when trying to use the same stream for the second row. T=
he reason it does not fail in the client driver is that the stream is not p=
assed to the server, it  is just used to instantiate the LOB in memory.

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