[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[ https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887232#comment-15887232 ] Bryan Pendleton commented on DERBY-6923: Thank you Gordon for the additional information. Can you attach the test program which produces this most recent crash? >From a quick check of the source code, it appears that the "parameterMetaData" >is NULL. I believe this crash is a different bug than the original bug, although perhaps they are related. parameterMetaData, I believe, is supposed to be constructed when the prepared statement has the "prepare" method invoked on it, but somehow that went wrong in this particular case? If possible, could you please open a new JIRA issue, attach the test program which produces the NullPointerException, and mark the new issue as "related to" this issue with a JIRA "link"? Thanks! > Passing a ClientClob or ClientBlob from another connection to an INSERT > statement results in 'null' being written. > -- > > Key: DERBY-6923 > URL: https://issues.apache.org/jira/browse/DERBY-6923 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.13.1.1 > Environment: Java 8 > MacOS > Windows >Reporter: Gordon Innes >Priority: Critical > Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java, > DerbyNetworkRead.java, DerbyNetworkWrite.java > > > When assigning a Blob or Clob from a ResultSet to a PreparedStatement > parameter on a second connection, null is written to the column instead. > Attached the same example using Embedded->Embedded, Embedded->Network, > Network->Embedded and Network->Network. > Only the Network->Network example exhibits the fault. > Originally discovered in HA-JDBC's sync code with 2 derby instances on > Windows. Example were tested using MacOS. Both were running on Oracle Java 8 > VMs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[
https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15886568#comment-15886568
]
Gordon Innes commented on DERBY-6923:
-
I've modified my NetworkOnly example to use a single connection. When I tried
running the section with non-matrialized Blob and Clob, it works as expected
with the correct data written.
However, the manually materialized section throws the following NullPointer
exception:
{quote}
Exception in thread "main" java.lang.NullPointerException
at
org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatementRequest.java:962)
at
org.apache.derby.client.net.NetStatementRequest.writeExecute(NetStatementRequest.java:166)
at
org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPreparedStatement.java:156)
at
org.apache.derby.client.am.ClientPreparedStatement.writeExecute(ClientPreparedStatement.java:1834)
at
org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2052)
at
org.apache.derby.client.am.ClientPreparedStatement.executeX(ClientPreparedStatement.java:1622)
at
org.apache.derby.client.am.ClientPreparedStatement.execute(ClientPreparedStatement.java:1607)
at DerbyNetworkOnly.main(DerbyNetworkOnly.java:68)
{quote}
> Passing a ClientClob or ClientBlob from another connection to an INSERT
> statement results in 'null' being written.
> --
>
> Key: DERBY-6923
> URL: https://issues.apache.org/jira/browse/DERBY-6923
> Project: Derby
> Issue Type: Bug
> Components: Network Client, Network Server
>Affects Versions: 10.13.1.1
> Environment: Java 8
> MacOS
> Windows
>Reporter: Gordon Innes
>Priority: Critical
> Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java,
> DerbyNetworkRead.java, DerbyNetworkWrite.java
>
>
> When assigning a Blob or Clob from a ResultSet to a PreparedStatement
> parameter on a second connection, null is written to the column instead.
> Attached the same example using Embedded->Embedded, Embedded->Network,
> Network->Embedded and Network->Network.
> Only the Network->Network example exhibits the fault.
> Originally discovered in HA-JDBC's sync code with 2 derby instances on
> Windows. Example were tested using MacOS. Both were running on Oracle Java 8
> VMs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[ https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884403#comment-15884403 ] Bryan Pendleton commented on DERBY-6923: Thanks Gordon. I had the same question about whether the cross-server access was relevant, and (independently) I also tried using just a single Network Server instance and the behavior did not change for me, either. However, I *do* notice in the code that the "locator" classes in the client driver have a member field of type "connection", so I suspect that the fact that you are using two different *connections* might be important. Since you have experimented with using a single server, perhaps you could further experiment with using a single *connection*? I am hopeful that somebody else in the Derby development community who may have more knowledge of the BLOB locator implementation may be able to offer further suggestions, otherwise a fair amount of study of the current implementation may be needed. > Passing a ClientClob or ClientBlob from another connection to an INSERT > statement results in 'null' being written. > -- > > Key: DERBY-6923 > URL: https://issues.apache.org/jira/browse/DERBY-6923 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.13.1.1 > Environment: Java 8 > MacOS > Windows >Reporter: Gordon Innes >Priority: Critical > Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java, > DerbyNetworkRead.java, DerbyNetworkWrite.java > > > When assigning a Blob or Clob from a ResultSet to a PreparedStatement > parameter on a second connection, null is written to the column instead. > Attached the same example using Embedded->Embedded, Embedded->Network, > Network->Embedded and Network->Network. > Only the Network->Network example exhibits the fault. > Originally discovered in HA-JDBC's sync code with 2 derby instances on > Windows. Example were tested using MacOS. Both were running on Oracle Java 8 > VMs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[ https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884380#comment-15884380 ] Gordon Innes commented on DERBY-6923: - Thanks for the detailed response. The delayed transfer of the data you describe certainly fits with the behaviour I'm seeing. Manually materializing the objects is a good workaround. The original HA-JDBC code that first found the issue with is designed to synchronise the databases without knowledge of the schema. It uses getObject and setObject to set up batches of inserts. So it will need to introduce special cases for Clob and Blob objects. I was wondering if the issue could be because the connections were on separate NetworkServer instances. As a quick test, I modified the DerbyNetworkOnly example to have both connections point to the same NetworkServer and the behaviour is still the same, i.e. null is written when using 'non-materialized' objects. > Passing a ClientClob or ClientBlob from another connection to an INSERT > statement results in 'null' being written. > -- > > Key: DERBY-6923 > URL: https://issues.apache.org/jira/browse/DERBY-6923 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.13.1.1 > Environment: Java 8 > MacOS > Windows >Reporter: Gordon Innes >Priority: Critical > Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java, > DerbyNetworkRead.java, DerbyNetworkWrite.java > > > When assigning a Blob or Clob from a ResultSet to a PreparedStatement > parameter on a second connection, null is written to the column instead. > Attached the same example using Embedded->Embedded, Embedded->Network, > Network->Embedded and Network->Network. > Only the Network->Network example exhibits the fault. > Originally discovered in HA-JDBC's sync code with 2 derby instances on > Windows. Example were tested using MacOS. Both were running on Oracle Java 8 > VMs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[ https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884310#comment-15884310 ] Bryan Pendleton commented on DERBY-6923: This background discussion from 10 years ago is probably worth reviewing? http://derby-dev.db.apache.narkive.com/cgD3FRUt/lifetime-of-blob-clob-objects-compatibility-issues > Passing a ClientClob or ClientBlob from another connection to an INSERT > statement results in 'null' being written. > -- > > Key: DERBY-6923 > URL: https://issues.apache.org/jira/browse/DERBY-6923 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.13.1.1 > Environment: Java 8 > MacOS > Windows >Reporter: Gordon Innes >Priority: Critical > Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java, > DerbyNetworkRead.java, DerbyNetworkWrite.java > > > When assigning a Blob or Clob from a ResultSet to a PreparedStatement > parameter on a second connection, null is written to the column instead. > Attached the same example using Embedded->Embedded, Embedded->Network, > Network->Embedded and Network->Network. > Only the Network->Network example exhibits the fault. > Originally discovered in HA-JDBC's sync code with 2 derby instances on > Windows. Example were tested using MacOS. Both were running on Oracle Java 8 > VMs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[ https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884309#comment-15884309 ] Bryan Pendleton commented on DERBY-6923: Assuming that this is in fact a strange behavior of Derby's locator implementation in the NetworkClient, DERBY-2496 is probably the relevant code to study. > Passing a ClientClob or ClientBlob from another connection to an INSERT > statement results in 'null' being written. > -- > > Key: DERBY-6923 > URL: https://issues.apache.org/jira/browse/DERBY-6923 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.13.1.1 > Environment: Java 8 > MacOS > Windows >Reporter: Gordon Innes >Priority: Critical > Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java, > DerbyNetworkRead.java, DerbyNetworkWrite.java > > > When assigning a Blob or Clob from a ResultSet to a PreparedStatement > parameter on a second connection, null is written to the column instead. > Attached the same example using Embedded->Embedded, Embedded->Network, > Network->Embedded and Network->Network. > Only the Network->Network example exhibits the fault. > Originally discovered in HA-JDBC's sync code with 2 derby instances on > Windows. Example were tested using MacOS. Both were running on Oracle Java 8 > VMs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6923) Passing a ClientClob or ClientBlob from another connection to an INSERT statement results in 'null' being written.
[
https://issues.apache.org/jira/browse/DERBY-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884306#comment-15884306
]
Bryan Pendleton commented on DERBY-6923:
Hi! Thanks for the clean and simple test programs.
Looking at your programs in detail, it seems like the crucial difference you're
exploring is between:
{code}
insertStatement.setClob(2, new
InputStreamReader(select.getClob(2).getAsciiStream()));
insertStatement.setBlob(3, select.getBlob(3).getBinaryStream());
{code}
versus
{code}
insertStatement.setClob(2, select.getClob(2));
insertStatement.setBlob(3, select.getBlob(3));
{code}
The Derby BLOB and CLOB implementation is a bit murky to me, I'm afraid, but I
believe that you are running into the behavior that the Derby documentation
describes here: http://db.apache.org/derby/docs/10.13/ref/rrefjdbc96386.html
{quote}
The Derby implementation of the java.sql.Blob and java.sql.Clob interfaces is
LOCATOR-based, meaning that the implementation provides a logical pointer to a
LOB rather than a complete copy of the object. Also, Derby does not materialize
a LOB when you use the BLOB or CLOB data type. You can, however, call methods
on a java.sql.Blob and java.sql.Clob object to materialize it (that is, to
retrieve the entire object or parts of it).
...
Use the getBlob and getClob methods of the java.sql.ResultSet interface to
retrieve a LOB using its locator. You can then materialize all or part of the
LOB by calling Blob and Clob methods. Alternatively, you can call the
ResultSet.getBytes method to materialize a BLOB, and you can call the
ResultSet.getString method to materialize a CLOB.
{quote}
In other words, I suspect that in your second block of code, you are executing
an INSERT statement in which the blob and clob values that you have provided as
parameters are "non-materialized".
But in the first block of code, you are executing an INSERT statement in which
the blob and clob values are "materialized", which occurred when you called
getBinaryStream and getAsciiStream
The behavior of locator-based large objects in Derby has historically been
quite a bit more complicated in client-server configurations than in embedded
configurations, which is I suspect why you are seeing the behavior only in the
client-server configuration.
In the client-server configuration, the blob/clob values have to be fully
copied from the server to the client in order to be "materialized", and then
have to be fully copied **back** from the client to the server when being
inserted into the other table.
So, I suspect what's going wrong is that the Derby JDBC client software is
supposed to detect when you have performed a setBlob() or setClob() with a
non-materialized blob or clob as the source object, and then should materialize
that blob when you execute the insert statement.
However, it seems like the Derby JDBC client is not doing that properly, with
the result that, in your case, things work fine if your program is careful to
materialize the blob itself, rather than depending on the Derby JDBC client to
do that.
That is, I feel like the behavior you are demonstrating is a bug, but I'm (a)
not sure how to fix it, and (b) trying to suggest that, in the short term, you
may need to continue to use the explicit materialization workaround you've
found in order to get the desired behavior in your program.
> Passing a ClientClob or ClientBlob from another connection to an INSERT
> statement results in 'null' being written.
> --
>
> Key: DERBY-6923
> URL: https://issues.apache.org/jira/browse/DERBY-6923
> Project: Derby
> Issue Type: Bug
> Components: Network Client, Network Server
>Affects Versions: 10.13.1.1
> Environment: Java 8
> MacOS
> Windows
>Reporter: Gordon Innes
>Priority: Critical
> Attachments: DerbyEmbeddedOnly.java, DerbyNetworkOnly.java,
> DerbyNetworkRead.java, DerbyNetworkWrite.java
>
>
> When assigning a Blob or Clob from a ResultSet to a PreparedStatement
> parameter on a second connection, null is written to the column instead.
> Attached the same example using Embedded->Embedded, Embedded->Network,
> Network->Embedded and Network->Network.
> Only the Network->Network example exhibits the fault.
> Originally discovered in HA-JDBC's sync code with 2 derby instances on
> Windows. Example were tested using MacOS. Both were running on Oracle Java 8
> VMs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
