Hi Andy,
Thanks for your reply. The wise thing would be restructuring through the
transactional mode of TDB as you also point out.
Best,
Anil.
On 23.01.2013 23:25, Andy Seaborne wrote:
On 23/01/13 14:50, A. Anil SINACI wrote:
Dear Jena users,
I need an advice on whether to use transactional TDB or
non-transactional one, and if I use non-transactional; when to use
TDB.sync.
As far as I understand from the tutorials, if I have never call a
transaction operation on a dataset (i.e. dataset.begin(..)), then my TDB
backed dataset is used in a non-transactional mode. With this kind of
usage, I think I need to properly sync database in order not to put the
data files into an inconsistent state. I hope I am correct up to this
point.
Correct.
I have a web application which uses Jena TDB as its data store. Multiple
users are signin-in in and manipulating data. My current problem is
that, if the JVM holding the servlet container shuts down (i.e. ctrl+c
command), and if I run the server again, then I get a
NullPointerException during the dataset creation:
"TDBFactory.createDataset(...);". I tried to avoid this exception with
TDB.sync after each write operation that I do, however this decreases
the performance a lot.
I can afford some missing information in the persistent store, however
the store becomes unreadable if closed (actually the JVM shuts down)
without a TDB.sync. On the other hand switching to transactional TDB
means that I need to employ a different architecture which will cost
much to me. To illustrate I want to give a small example, my bean-like
classes all extend OntClassImpl, hence in their constructors I call
"super(node, graph);" which automatically adds the corresponding triples
to my graph. It will be hard to edit this architecture to insert the
begin and end parts of transactions.
Lack of sync() does not miss some specific triples - it will loose
some internal datastructure data so the database will be corrupt and
unusable. There isn't a trade off to
You can use transactions - it should be faster than needing to sync at
every point.
Open a transaction at the beginning of the web app operation and
commit it at the end. Transactions are per-thread so concurrency on
the same database will work. If you do not use transactions, you need
manage concurrency yourself (or get a corrupt database, if TDB does
not notice with it internal checking).
If you know it's a read operation use a READ transaction. They are
more efficient as well as being good practice.
So, roughly
web_operation()
{
dataset.begin(WRITE or READ)
try {
yourCode(dataset) // no concurrency control needed.
commit()
} ....
and yourcode does not have to be transaction aware.
Andy
