db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-3870) Concurrent Inserts of rows with XML data results in an exception
Date Thu, 19 May 2011 12:36:47 GMT

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

Knut Anders Hatlen updated DERBY-3870:

    Attachment: d3870-1a.stat

The attached patch (1a) seems to fix the bug and allow XML operators to be executed concurrently.

The patch makes the following changes:

1) The SqlXmlUtil instance isn't stored in the compiled plan. Instead, byte code is generated
so that a new instance is created the first time the operator is used in an activation (and
reused subsequently in the same activation only).

2) Since the SqlXmlUtil instance is no longer persisted, it no longer implements Formatable,
which allowed for removal of a number of methods in the class, as well as entries for the
class in RegisteredFormatIds and StoredFormatIds.

3) Created a new  abstract super-class of UnaryOperatorNode, BinaryOperatorNode and TernaryOperatorNode,
in which code that generates byte-code for the different XML operators could be shared. Currently,
their only common super-class is ValueNode, which sounds too general for code that's only
used by operator nodes.

4) Enables XMLConcurrencyTest in the regression test suite.

I've verified that we still don't create/compile the SqlXmlUtil instance for each row with
the patch. We do create an instance and compile the XML query on the first row that uses the
operator per activation. This also means that if you re-execute a previously executed PreparedStatement,
the cached value will be used.

In addition to the per-activation compilation of the XML query, we still compile the XML query
when creating the SQL query execution plan. This isn't strictly necessary anymore, since the
compiled XML query will now be thrown away instead of being stored in the plan. I left the
code in there so that syntax errors in the XML query would still generate a compile-time error
instead of being delayed to execution-time. I'm open to changing this, but wanted to prevent
any behaviour changes in the first iteration.

Other potential improvements:

- More common code can probably be pulled from the *naryOperatorNode classes up to their new
parent class. But that's outside the scope of this issue.

- As far as I can see, there's no reason to create a new SqlXmlExecutor instance for every
row, as we currently do. The instances are (effectively) immutable, and contain the same values
for all rows, so it may make sense to cache the SqlXmlExecutor instances instead of the SqlXmlUtil
instances (which can be retrieved from the executors anyway).

- The SqlXmlExecutor class contains a comment indicating that it belongs in the types package,
but it was placed in the execute package because it accessed the Activation class, and the
types layer shouldn't depend on the SQL layer. SqlXmlExecutor no longer accesses the Activation
class, so it may be possible to move it to the types package now.

I've run all the regression tests on an earlier version of the patch without seeing any failures.
Rerunning the tests now just to be safe, since I've made some small changes to the patch later.

> Concurrent Inserts of rows with XML data results in an exception
> ----------------------------------------------------------------
>                 Key: DERBY-3870
>                 URL: https://issues.apache.org/jira/browse/DERBY-3870
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,,,
>         Environment: System: MS windows server 2003 standard edition service pack 2.
Derby is run as a server on port 1527.
>            Reporter: Royi Ronen
>            Assignee: Knut Anders Hatlen
>              Labels: derby_triage10_5_2
>         Attachments: Copy of derby.log, DerbyMultiInsertXmlException.zip, d3870-1a.diff,
d3870-1a.stat, d3870-junit.diff
> We insert rows into a table using the following prepared statement (through JDBC):
> INSERT INTO USER1.PSTORE values(?,?, XMLPARSE(document CAST (? AS CLOB) preserve whitespace))
> where each of the ?'s are replaced with a string.
> One thread runs fine. Two or more result in the following exception: 
> org.apache.derby.client.am.SqlException: Java exception: 'FWK005 parse may not be called
while parsing.: org.xml.sax.SAXException'.
> 	at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
> 	at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
> We believe that this comes from the dBuilder.parse(InputSource) method.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message