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 duplicatess (which won't an a different duplicate).
And maybe the LOCK TABLE needs to be further out.
(/me hopes Damian has better insight here)
Andy
On 15/04/13 20:58, Lebling, David (US SSA) wrote:
Andy,
Are you suggesting the use of
Connection.setTransactionIsolation(something-other-than-TRANSACTION_READ_COMMITTED),
which is the default? The SDB implementation already uses setAutoCommit,
etc.
I tried all higher values for setTransactionIsolation() than the
default, using a freshly populated database, and the results are that at
levels Connection.TRANSACTION_REPEATABLE_READ and
Connection.TRANSACTION_SERIALIZABLE after a while the following
exception is thrown:
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] (PlannerInterfaceServiceEndPointImpl.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)
In addition, these level settings had no impact on the error conditions I
highlighted in my original message.
Obviously I'm missing something here. Were you actually suggesting something
different?
Dave
-----Original Message-----
From: Andy Seaborne [mailto:[email protected]]
Sent: Monday, April 15, 2013 10:10 AM
To: [email protected]
Subject: Re: Concurrency in Jena/SDB
On 15/04/13 14:51, Lebling, David (US SSA) wrote:
Andy,
Which part of that document is the part that might help? My code
already creates a new Store for each transaction. My code already uses
begin/commit.
The fact you can manage the JDBC connection separately from the Store - that
can tie to receiving servlet requests quite well.
Andy
You asked:
I was hoping you might have some guidance as to what you mean by "You
need to control the JDBC transaction in your code to get isolation
between JVMs."
(I've read the document many times previously, by the way.)
Dave L.
-----Original Message----- From: Andy Seaborne
[mailto:[email protected]] Sent: Monday, April 15, 2013 9:42 AM To:
[email protected] Subject: Re: Concurrency in Jena/SDB
This might help:
http://jena.apache.org/documentation/sdb/javaapi.html#connection-manag
ement
Andy
