So every call to a method of Model or OntModel is done in a separate transaction? This could easily explain the poor performance I am getting, and those of others who have complained about SDB performance in this group.
Your code example is very sparse. Are there calls to make to get to an associated JDBC transaction? All of the JDBC connection info is described in Jena's assembler files, so it seems like an API should be available to access the needed JDBC objects. -----Original Message----- From: Damian Steer [mailto:[email protected]] On Behalf Of Damian Steer Sent: Monday, April 15, 2013 9:27 AM To: [email protected] Subject: Re: Concurrency in Jena/SDB On 15 Apr 2013, at 12:35, "Lebling, David (US SSA)" <[email protected]> wrote: > Andy, > > 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." > > Is there some interface in SDB that will accomplish this, or does this > require SQL-implementation-specific code, thus tearing down the SDB façade? > If it does require such implementation-specific code, do you have any > pointers to examples which do it correctly? Is it necessary to write one's > own transaction begin/commit/abort methods? SDB (as you'd expect) handles transactions itself by default. All model operations happen in a single transaction, with a minor wrinkle around really big loads (it will start committing every 20,000 triples iirc to avoid huge transactions). You can also wrap operations like this to get some of that behaviour across a number of operations: model.notifyEvent(GraphEvents.startRead) ; try { ... do add/remove operations ... } finally { model.notifyEvent(GraphEvents.finishRead) ; } However it's not especially smart, so you can take control of the transaction yourself by setting autocommit to false on the JDBC connection. SDB will then assume the client is responsible for managing the transactions. Just remember to commit() and reset autocommit when you finish. Damian
