Personally, I would instrument TransactionManager with a conditional "throw new IOException(...)" to simulate this kind of failure mode at will.

alex


On 1/22/08, Kevin Day <kevin@trumpetinc.com> wrote:
Next question for the group:  How do we unit test this?
 
- K
 
----------------------- Original Message -----------------------
  
From: "Alex Boisvert" <boisvert@intalio.com>
To: "Kevin Day" <kevin@trumpetinc.com>
Date: Tue, 22 Jan 2008 11:49:04 -0800
Subject: Re: [Jdbm-developer] Need help on .db file optimisation | JDBM
  
On 1/22/08, Kevin Day < kevin@trumpetinc.com> wrote:
Alex-
 
I admit that my current approach to fixing this is a sledgehammer, when a scalple is called for (we had to get something in place quickly).
 
I'm thinking something along the following (definitely could use some input from everyone else on whether you think this would do the trick):
 
I'm pretty sure that the failure mechanism is as follows:
 
1.  The write to the log fails
2.  A subsequent write to the log is attempted that does not fail
 
This would normally result in a log that couldn't be played back - but we don't play the log back unless we stop and re-start the app.  We write to the db file from memory when we commit the transaction, so we happily write data to db, even though the transaction failed.
 
In TransactionManager.commit() and TransactionManager.sync(), I believe that we can bracket the method with a try/catch and shut down the transaction manager if an IOException is thrown.  Basically, make it so it *always* throws IOException once the first IOException is thrown.  I'm pretty sure that we are well past the point of serialization or anything else that could cause an IOException other than a true failure to write to disk...
 
What do you think?

Yes, I think this makes a lot of sense.

alex
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Jdbm-developer mailing list
Jdbm-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-developer



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jdbm-developer mailing list
Jdbm-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-developer