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

Reply via email to