incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Helsen <>
Subject Re: TDB: release process
Date Mon, 09 Jan 2012 15:07:28 GMT
Andy, others,

I have been testing TxTDB on my end and functionally, things are looking 
good. I am not able to see any immediate problems anymore. Of course, 
there may still be more exotic things left, but those can probably managed 
in am minor release. However, now that it is getting good on the 
functional end, I am starting to check the non-functional characteristics, 
especially speed and scalability (in terms of multiple clients). For this 
I use a test suite with about 35 different queries and I compare the 
performance against Jena 2.6.3/ARQ 2.8.5 and TDB 0.8.7 because that is the 
version we currently use in the release of our product.. I am comparing 
these numbers then with Jena/ARQ 2.7.0 and TDB 0.9.0 (20111229) and the 
transaction API. I realize this partially comparing apples to pears but 
from our perspective, we need to see how the bottomline changes in terms 
of query speed when we increase the number of concurrent clients.

I have detailed numbers, but before I start sharing these, I want to know 
if there is anything I could/should do to tune ARQ/TxTDB in terms of 
performance. For instance, I wonder if there are still a whole range of 
checks active which I can/should turn off now that we are functionally 
more sound. For completeness, I should add that we don't use any 
optimization (i.e. we run with none.opt )



Andy Seaborne <>
01/08/2012 02:28 PM
TDB: release process

The release of core/ARQ etc. hasn't lead to any immediate disasters (but 
there is still time!) so we can move on to TDB.

As far as I'm concerned, the code in the current snapshot and in SVN is 
release candidate code (JENA-102 is fixed) and if people don't test it 
(I've pinged jena-users@), then they risk it taking longer to get a 
released version with fixes.

I need to write the transaction API documentation and there is something 
odd in the prefix handling but as  far as I can see, it's been odd for 
some time, maybe all time; it needs reworking, not fixing so shouldn't 
block a release.


PS Fuseki snapshot is using TDB transactions now.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message