[
https://issues.apache.org/jira/browse/JENA-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-447:
-------------------------------
Description:
Using transaction isolation settings of TRANSACTION_REPEATABLE_READ or
TRANSACTION_SERIALIZABLE to improve concurrency safety with multiple readers
and writers in different JVMs eventually produces the following warning and
then error from an SQLException:
WARN [tomcat-http--10] (SDBConnection.java:338) - execUpdate: SQLException
ERROR: duplicate key value violates unique constraint "nodes_pkey"
Detail: Key (hash)=(-8555076428185164481) already exists.
LOCK TABLE Nodes; INSERT INTO Nodes (hash, lex, lang, datatype, type) SELECT
NNodeQuads1740763164.n0 , NNodeQuads1740763164.n1 , NNodeQuads1740763164.n2 ,
NNodeQuads1740763164.n3 , NNodeQuads1740763164.n4 FROM NNodeQuads1740763164
LEFT JOIN Nodes ON (NNodeQuads1740763164.n0=Nodes.hash)
WHERE Nodes.hash IS NULL
ERROR [tomcat-http--10] (xxx.java:237) - lp:PI2 comp:PIS id:12 action:exception
msg:submitExternalRequest
com.hp.hpl.jena.sdb.SDBException: Exception flushing
at
com.hp.hpl.jena.sdb.layout2.TupleLoaderBase.flush(TupleLoaderBase.java:234)
at
com.hp.hpl.jena.sdb.layout2.TupleLoaderBase.finish(TupleLoaderBase.java:169)
at
com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.commitTuples(LoaderTuplesNodes.java:306)
at
com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.flushTriples(LoaderTuplesNodes.java:235)
at
com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.finishBulkUpdate(LoaderTuplesNodes.java:90)
at
com.hp.hpl.jena.sdb.graph.GraphSDB.finishBulkUpdate(GraphSDB.java:310)
at
com.hp.hpl.jena.sdb.graph.EventManagerSDB.notifyEvent(EventManagerSDB.java:41)
at
com.hp.hpl.jena.rdf.model.impl.ModelCom.notifyEvent(ModelCom.java:1543)
Further details on request, but the setup is large and complex, so it would be
very hard to produce a "simple, repeatable case."
Andy Seaborne commented when this was first reported:
> Seeing that error message makes it a bit clearer to me. It's something
> to do with the bulk loader (NNodeQuads1740763164) and some othe
> raction has already inserted a node. As the possible values for a row in the
> node table are fixed for a given primary key, I wonder if it's possible to
> insert but ignore duplicates (which won't an a different duplicate).
> And maybe the LOCK TABLE needs to be further out.
> (/me hopes Damian has better insight here)
Dave Lebling
was:
Using transaction isolation settings of TRANSACTION_REPEATABLE_READ or
TRANSACTION_SERIALIZABLE to improve concurrency safety with multiple readers
and writers in different JVMs eventually produces the following warning and
then error from an SQLException:
WARN [tomcat-http--10] (SDBConnection.java:338) - execUpdate: SQLException
ERROR: duplicate key value violates unique constraint "nodes_pkey"
Detail: Key (hash)=(-8555076428185164481) already exists.
LOCK TABLE Nodes; INSERT INTO Nodes (hash, lex, lang, datatype, type) SELECT
NNodeQuads1740763164.n0 , NNodeQuads1740763164.n1 , NNodeQuads1740763164.n2 ,
NNodeQuads1740763164.n3 , NNodeQuads1740763164.n4 FROM NNodeQuads1740763164
LEFT JOIN Nodes ON (NNodeQuads1740763164.n0=Nodes.hash)
WHERE Nodes.hash IS NULL
ERROR [tomcat-http--10] (xxx.java:237) - lp:PI2 comp:PIS id:12 action:exception
msg:submitExternalRequest
com.hp.hpl.jena.sdb.SDBException: Exception flushing
at
com.hp.hpl.jena.sdb.layout2.TupleLoaderBase.flush(TupleLoaderBase.java:234)
at
com.hp.hpl.jena.sdb.layout2.TupleLoaderBase.finish(TupleLoaderBase.java:169)
at
com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.commitTuples(LoaderTuplesNodes.java:306)
at
com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.flushTriples(LoaderTuplesNodes.java:235)
at
com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.finishBulkUpdate(LoaderTuplesNodes.java:90)
at
com.hp.hpl.jena.sdb.graph.GraphSDB.finishBulkUpdate(GraphSDB.java:310)
at
com.hp.hpl.jena.sdb.graph.EventManagerSDB.notifyEvent(EventManagerSDB.java:41)
at
com.hp.hpl.jena.rdf.model.impl.ModelCom.notifyEvent(ModelCom.java:1543)
Further details on request, but the setup is large and complex, so it would be
very hard to produce a "simple, repeatable case."
Andy Seabourne commented when this was first reported:
> Seeing that error message makes it a bit clearer to me. It's something
> to do with the bulk loader (NNodeQuads1740763164) and some othe
> raction has already inserted a node. As the possible values for a row in the
> node table are fixed for a given primary key, I wonder if it's possible to
> insert but ignore duplicates (which won't an a different duplicate).
> And maybe the LOCK TABLE needs to be further out.
> (/me hopes Damian has better insight here)
Dave Lebling
> SDB - SQLException duplicate key value in model.commit when transaction
> isolation > TRANSACTION_READ_COMMITED
> --------------------------------------------------------------------------------------------------------------
>
> Key: JENA-447
> URL: https://issues.apache.org/jira/browse/JENA-447
> Project: Apache Jena
> Issue Type: Bug
> Components: SDB
> Affects Versions: SDB 1.3.5
> Environment: Windows 7, Ubuntu Linux
> Reporter: Dave Lebling
>
> Using transaction isolation settings of TRANSACTION_REPEATABLE_READ or
> TRANSACTION_SERIALIZABLE to improve concurrency safety with multiple readers
> and writers in different JVMs eventually produces the following warning and
> then error from an SQLException:
> WARN [tomcat-http--10] (SDBConnection.java:338) - execUpdate: SQLException
> ERROR: duplicate key value violates unique constraint "nodes_pkey"
> Detail: Key (hash)=(-8555076428185164481) already exists.
> LOCK TABLE Nodes; INSERT INTO Nodes (hash, lex, lang, datatype, type) SELECT
> NNodeQuads1740763164.n0 , NNodeQuads1740763164.n1 , NNodeQuads1740763164.n2 ,
> NNodeQuads1740763164.n3 , NNodeQuads1740763164.n4 FROM NNodeQuads1740763164
> LEFT JOIN Nodes ON (NNodeQuads1740763164.n0=Nodes.hash)
> WHERE Nodes.hash IS NULL
> ERROR [tomcat-http--10] (xxx.java:237) - lp:PI2 comp:PIS id:12
> action:exception msg:submitExternalRequest
> com.hp.hpl.jena.sdb.SDBException: Exception flushing
> at
> com.hp.hpl.jena.sdb.layout2.TupleLoaderBase.flush(TupleLoaderBase.java:234)
> at
> com.hp.hpl.jena.sdb.layout2.TupleLoaderBase.finish(TupleLoaderBase.java:169)
> at
> com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.commitTuples(LoaderTuplesNodes.java:306)
> at
> com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.flushTriples(LoaderTuplesNodes.java:235)
> at
> com.hp.hpl.jena.sdb.layout2.LoaderTuplesNodes.finishBulkUpdate(LoaderTuplesNodes.java:90)
> at
> com.hp.hpl.jena.sdb.graph.GraphSDB.finishBulkUpdate(GraphSDB.java:310)
> at
> com.hp.hpl.jena.sdb.graph.EventManagerSDB.notifyEvent(EventManagerSDB.java:41)
> at
> com.hp.hpl.jena.rdf.model.impl.ModelCom.notifyEvent(ModelCom.java:1543)
> Further details on request, but the setup is large and complex, so it would
> be very hard to produce a "simple, repeatable case."
> Andy Seaborne commented when this was first reported:
> > Seeing that error message makes it a bit clearer to me. It's something
> > to do with the bulk loader (NNodeQuads1740763164) and some othe
> > raction has already inserted a node. As the possible values for a row in
> > the node table are fixed for a given primary key, I wonder if it's possible
> > to insert but ignore duplicates (which won't an a different duplicate).
> > And maybe the LOCK TABLE needs to be further out.
> > (/me hopes Damian has better insight here)
> Dave Lebling
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
