Paolo Castagna wrote:
NodeTableTrans.java in the private finish() method,
why should we close the Journal if a transaction gets aborted?
Index: src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
===================================================================
--- src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
(revision 1158186)
+++ src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
(working copy)
@@ -197,7 +197,6 @@
{
passthrough = true ;
nodeTableJournal = null ;
- close() ;
}
@Override
Better:
Index: src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
===================================================================
--- src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java (revision
1158186)
+++ src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
(working copy)
@@ -196,8 +196,8 @@
private void finish()
{
passthrough = true ;
+ nodeTableJournal.close() ;
nodeTableJournal = null ;
- close() ;
}
@Override
I think this was the cause of the issue described below in my
original message.
I came to the conclusion that it's not 'safe' nor wise calling
StoreConnection.reset() and physically delete files on disk
many time. With memory mapped files on Linux a file handler is
kept around until the JVM exits. You can quickly run out of file
handlers.
There is little, if not nothing, we can do about this other
than say: don't do that. Or, if you really need it, be aware
of the problem and create another JVM to do this.
Isn't it?
Paolo
Paolo
Andy Seaborne wrote:
AbstractTestTransSeq.trans_readBlock_04() exhibits this error. I
thought it was a false test for a while btu having had a chance to
look at it, it looks good to me.
The key pattern is
READ(start)...WRITE(abort)-WRITE(commit) ... READ(Finish).
The .commit fails.
Investigations continue ....
(other changes incorporated whenever I next commit code)
Andy
On 16/08/11 12:21, Paolo Castagna wrote:
Hi Andy,
while I was running TestTransSystem and double checking the number of
open files does not grow indefinitely, I noticed that the TDB indexes
get deleted at each iteration (but they are not recreated).
This is my attempt at fixing that:
Index:
src/test/java/com/hp/hpl/jena/tdb/transaction/TestTransSystem.java
===================================================================
--- src/test/java/com/hp/hpl/jena/tdb/transaction/TestTransSystem.java
(revision 1158186)
+++ src/test/java/com/hp/hpl/jena/tdb/transaction/TestTransSystem.java
(working copy)
@@ -126,6 +126,7 @@
private static void clean()
{
+ StoreConnection.reset() ;
if ( ! LOC.isMem() )
FileOps.clearDirectory(LOC.getDirectoryPath()) ;
}
However, when I run the modified TestTransSystem I get this error:
"Different ids allocated: expected [0000000000000000], got
[0000000000000000]"
which is not helpful.
This:
Index: src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
===================================================================
--- src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
(revision 1158186)
+++ src/main/java/com/hp/hpl/jena/tdb/transaction/NodeTableTrans.java
(working copy)
@@ -144,7 +144,7 @@
Node node = x.getRight() ;
NodeId nodeId2 = base.getAllocateNodeId(node) ;
if ( ! nodeId2.equals(mapFromJournal(nodeId)) )
- throw new TDBException(String.format("Different ids allocated:
expected %s, got %s\n", nodeId, nodeId2)) ;
+ throw new TDBException(String.format("Different ids allocated:
expected %s, got %s\n", mapFromJournal(nodeId), nodeId2)) ;
}
}
gives us:
"Different ids allocated: expected [000000000000000E], got
[0000000000000000]"
I still do not know what's going wrong, I am posting here to see if
you have any useful suggestion.
Thanks,
Paolo
Andy Seaborne wrote:
On 15/08/11 13:57, Paolo Castagna wrote:
Hi Andy,
NodeTableTrans has an empty implementation for the close() method.
Shouldn't we call close on journal (i.e. journal.close()) and,
possibly,
on base (i.e. base.close())?
I can easily run into troubles using TestTransSystem with an on-disk
location instead of an in-memory one. After a while, you hit the
problem: "Too many open files".
Calling journal.close() seems to fix it.
Paolo
Yes - it does seem to fix it although some tests are affected (the
test look wrong). The intent was (I think) to allow for reusable
transaction objects to avoid the churn cost of java objects but it's a
false economy.
Andy
