The latest version of Jena TDB adds atomic transactions (version 0.9.0+) See http://jena.apache.org/documentation/tdb/tdb_transactions.html for documentation: The following limitations are listed: - Bulk loads: the TDB bulk loader is not transactional - Nested transactions are not supported. - Some active transaction state is held exclusively in-memory, limiting scalability. - Long-running transactions. Read-transactions cause a build-up of pending changes; - If a single read transaction runs for a long time when there are many updates, the system will consume a lot of temporary resources. On Tue, May 29, 2012 at 7:00 PM, Fleming, Declan <[log in to unmask]> wrote: > Hi Ravi - I'll let some of my more technical folks chime in, but we do a > bunch with RDF and have found every triplestore we've tried very limited in > handling transactions. Reading and writing at the same time causes a > deadlock that's a mess to keep clean. So, we went back where we started > and created a triplestore using SQL with big tables of triples. We cheat a > little bit with a fourth column for ID and a fifth that helps speed up > blank node searching. This has helped us avoid these transactional > problems we were having, and the performance is quite good for ingest. > > Most of our searching is done by stuffing the triples into solr in a JSON > format, so we don't rely on the backend data store for that much. We also > sync the SQL triples to Allegrograph in case we need deeper SPARQL things, > but we're thinking of shedding this from our architecture. > > Declan > > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Ravi Shankar > Sent: Tuesday, May 29, 2012 12:12 AM > To: [log in to unmask] > Subject: [CODE4LIB] triple stores ??? > > We (DLSS at Stanford Libraries) are planning to use a triple store for > storing and retrieving annotations (in RDF) on digital objects. We are > currently looking at open-source triple stores such as 4store, Virtuoso, > Jena SDB and Mulgara. Are you currently using a triple store or > contemplating on using one? How would you evaluate 'your' triple store > along the lines of 1) ease of setup, 2) scalability, 3) query performance, > 3) bulk load performance, 4) access api, 5) documentation and 6) community > support? > > Highly appreciate your thoughts, ideas and suggestions. > > Thanks, > Ravi Shankar >