On 1/22/08, Kevin Day <kevin@trumpetinc.com> wrote:
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.