I can accept that history has caused there to be multiple APIs. And that some 
of your documentation may be based on older APIs due to a limited set of staff 
resources who has not had time to rewrite documentation. But it would be 
immensely useful for someone coming in fresh to Jena to know which APIs are the 
new and recommended ones, and which are there due to history and are primarily 
there for backwards compatibility, etc.

Your emails yesterday and today have raised some questions in my mind about 
Jena caching and transactions. I want to review the docs once more and then I 
will prepare an email with some questions about the interaction of caching and 
transactions.

If I get a project funded to use Jena, I suspect I will also get involved in 
contributing to Jena, once I have a thorough understanding of it.

-----Original Message-----
From: Andy Seaborne [mailto:[email protected]] 
Sent: Tuesday, April 30, 2013 6:22 AM
To: [email protected]
Subject: Re: random, periodic TDB file exception

On 27/04/13 18:05, David Jordan wrote:
>
> Thanks once again, Andy.
>
> Perhaps the most relevant line from the transaction web page is the 
> following sentence: "A TDB-backed dataset can be used 
> non-transactionally but once used in a transaction, it should be used 
> transactionally after that."
>
> I had been using it non-transactionally, which seemed to work fine.
> But then I put in some use of TDB transactions for some updates, but 
> not for some updates are for any read accesses, and that is when the 
> problems started showing up. The docs read as if encasing read 
> operations in a read transaction are not going to impact performance, 
> so I will convert everything to be transaction based. It is 
> unfortunate that there does not seem to be a single, consistent API 
> for doing transactions that works for both TDB and SDB. But based on 
> the performance numbers we have been getting, I think we will stick 
> with TDB, SDB was just too slow.

Read transactions are cheap; they are very cheap when there isn't a writer 
around at the point when it starts becaus ethen they are no more than a 
read-only wrapper on the raw database.

Yes - it would be nice to have a consistent API.  History mainly.  They could 
be brought back together if one or more people step in to contribute to SDB.

        Andy

Reply via email to