Hi there,
Which version is this?
What OS are you running and what filing system for the DB?
On 21/02/14 10:28, Jean-Marc Vanel wrote:
I'm encountering every now and then TDBTransactionException's. These errors
may be due to my code not respecting the transaction gotchas, but also to
real bugs. These errors may be due to my code not respecting the
transaction gotchas, but also to real bugs.
The context : I'm developing Swing applications
(DataGUI<http://svn.code.sf.net/p/eulergui/code/trunk/eulergui/html/documentation.html#Data1>
,
DomainApplication<http://svn.code.sf.net/p/eulergui/code/trunk/eulergui/html/documentation.html#L7253>
) that accumulate documents from the web in a TDB store that is used as a
cache.
The writings occur in threads (Scala futures) associated to the URI
downloaded, and to the named graph.
Also, the user can add triples (in a special named graph) that are at once
commited.
So, there is plenty of room for errors, plus the application is sometimes
killed.
That might explain one occurrence of the exceptions - the bad checksum.
If so, it's safe - the transaction was not truly committed and the app
wasn't told it was.
Here are examples of errors:
Do you longer stacktraces for each one?
[ERROR] - 2014-02-21 09:54:52,181 [ForkJoinPool-1-worker-1] TDB
(JournalControl.java:replay:259)
Exception during journal replay
The journal couldn't be replayed because the last entry was messed up
but that's not surprising if ...
com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Checksum
error reading from the Journal.
(ditto)
Exception after commit point : transaction commited but internal
status not recorded properly
[commit point is the internal commit - the journal has been sync'ed]
An attempt to commit failed during writing the transaction log - there
should be an exception stacktrace.
The transaction did not commit properly from the applications point of
view and it all depends on the journal. The journal is the ultimate
arbiter of what committed and what didn't based on recovery.
com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Checksum
error reading from the Journal.
Something else - a way to cause this is to exit the JVM forcefully
(while a journal entry is being written).
I need some advice about debugging, like displaying dataset, graph, journal
status, or adding assertions, or whatever is possible. I'm willing to
contribute to make TDB more robust by providing repeatable situations.
Another question is : how to repair a broken TDB ?
Attempt to start up TDB once, ignore any errors - this commits any
pending but complete transactions in the journal. The last one about
Checksum error reading should be the last transaction and it's not
really committed from an external recovery point of view.
Exit, then delete the journal file. Restart. Take a separate backup.
Or maybe the question is : can a TDB be broken at all, or is it my bad
application code that repeatedly creates similar problems?
If you run two copies of your code at the same time, then you will break
the database.
is your environment doing any classlaoder games? If so, it might have
two copies of the TDB engine running which is similar recipe for
disaster (two copies of the statics that manage the database state).
Kind regards
Andy
