I am looking at finally biting the bullet and transitioning from SDB to TDB. The first step is to come up with a level-of-effort estimate to see if this fits in our budget.
We are using Jena 2.11.0 and SDB 1.4.0. We have a set of five web services (which can be in separate JVMs) that use SDB as an OWL storage device. The items stored are named graphs. These are read, modified in memory (sometimes through inference, sometimes though pure Java code adding and removing and modifying statements), and written back out. We also use SPARQL queries on the union graph to find graphs of interest. Although currently there are a fairly small number of these named graphs, we want to be able to expand the system to hold a much larger number. One of the stumbling blocks with SDB was a bug in its multi-JVM concurrency code that wasn't fixed due to lack of SDB support. All interactions with the SDB database are through a single class which implements an interface with read, write, delete, find, etc. on named graphs and open and close on the database itself. Any advice on how to go about architecting and implementing a TDB version of the above would be appreciated. More details can be supplied if needed, of course. Thanks, Dave Lebling