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.
(I've read the document many times previously, by the way.) Dave L. -----Original Message----- From: Andy Seaborne [mailto:a...@apache.org] Sent: Monday, April 15, 2013 9:42 AM To: users@jena.apache.org Subject: Re: Concurrency in Jena/SDB This might help: http://jena.apache.org/documentation/sdb/javaapi.html#connection-management Andy On 15/04/13 14:38, David Jordan wrote: > > 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:cm...@bristol.ac.uk] On Behalf Of Damian Steer > Sent: Monday, April 15, 2013 9:27 AM > To: users@jena.apache.org > Subject: Re: Concurrency in Jena/SDB > > > On 15 Apr 2013, at 12:35, "Lebling, David (US SSA)" > <david.lebl...@baesystems.com> 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 >
