You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jena.apache.org by an...@apache.org on 2011/08/15 13:59:06 UTC
svn commit: r1157790 -
/incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Author: andy
Date: Mon Aug 15 11:59:06 2011
New Revision: 1157790
URL: http://svn.apache.org/viewvc?rev=1157790&view=rev
Log:
JENA-95 Close node dat file after recovery.
Modified:
incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Modified: incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
URL: http://svn.apache.org/viewvc/incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java?rev=1157790&r1=1157789&r2=1157790&view=diff
==============================================================================
--- incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java (original)
+++ incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java Mon Aug 15 11:59:06 2011
@@ -216,6 +216,7 @@ public class JournalControl
NodeTableTrans ntt = new NodeTableTrans(objFilename, baseNodeTable, new IndexMap(recordFactory), dataJrnl) ;
ntt.append() ;
ntt.close() ;
+ dataJrnl.close() ;
baseNodeTable.sync() ;
}
if ( jrnlFile.exists() )
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Paolo Castagna <ca...@googlemail.com>.
I though I've found the problem... but I didn't.
However, shouldn't we close the Journal when we expel a Location in
StoreConnection or when we do a reset?
Index: src/main/java/com/hp/hpl/jena/tdb/StoreConnection.java
===================================================================
--- src/main/java/com/hp/hpl/jena/tdb/StoreConnection.java (revision 1158186)
+++ src/main/java/com/hp/hpl/jena/tdb/StoreConnection.java (working copy)
@@ -107,6 +107,7 @@
return ;
if ( ! force && sConn.transactionManager.activeTransactions() )
throw new TDBTransactionException("Can't expel: Active
transactions for location: "+location) ;
+ sConn.transactionManager.getJournal().close() ;
sConn.baseDSG.close() ;
cache.remove(location) ;
}
It doesn't make the problem below to go away.
Still searching...
Paolo
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
>
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Andy Seaborne <an...@epimorphics.com>.
Paolo,
It is to do with closing ... in fact, being too neat and tidy on closing.
Nodes are written inside the transaction - the data goes to the
NodeTableTrans journal file, which is an ObjectFileStorage.
nodeTableJournal.close() is going to call journal.close so whether
nodeTableJournal.close or direct journal.close is called does not matter
much.
What does matter is that when ObjectFileStorage is gracefully closed, it
flushes to disk. ObjectFileStorage has a write buffer (dft 8K).
There is data in it from the transaction which is calling abort. In a
large transaction, the buffer may have flushed anyway.
Result: bytes are written to the journal on disk on abort or before. Oops.
The design does allow for reuse of data journals (not used) so journals
are not cleared at transaction start.
Solution: truncate the file before closing, no data written and any data
already written is removed.
To allow for concatenated use of the file, the start point in journal on
each transaction begin is recorded and on abort, the system truncates to
that point.
2* TestTransSystem (mem and disk) running in the background as I type.
Andy
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Paolo Castagna <ca...@googlemail.com>.
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
>>>
>
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Paolo Castagna <ca...@googlemail.com>.
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
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
>>
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Andy Seaborne <an...@epimorphics.com>.
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
>
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Paolo Castagna <ca...@googlemail.com>.
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
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Andy Seaborne <an...@epimorphics.com>.
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
Re: svn commit: r1157790 - /incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
Posted by Paolo Castagna <ca...@googlemail.com>.
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
andy@apache.org wrote:
> Author: andy
> Date: Mon Aug 15 11:59:06 2011
> New Revision: 1157790
>
> URL: http://svn.apache.org/viewvc?rev=1157790&view=rev
> Log:
> JENA-95 Close node dat file after recovery.
>
> Modified:
> incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
>
> Modified: incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java
> URL: http://svn.apache.org/viewvc/incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java?rev=1157790&r1=1157789&r2=1157790&view=diff
> ==============================================================================
> --- incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java (original)
> +++ incubator/jena/Experimental/TxTDB/trunk/src/main/java/com/hp/hpl/jena/tdb/transaction/JournalControl.java Mon Aug 15 11:59:06 2011
> @@ -216,6 +216,7 @@ public class JournalControl
> NodeTableTrans ntt = new NodeTableTrans(objFilename, baseNodeTable, new IndexMap(recordFactory), dataJrnl) ;
> ntt.append() ;
> ntt.close() ;
> + dataJrnl.close() ;
> baseNodeTable.sync() ;
> }
> if ( jrnlFile.exists() )
>
>