how do i read a log file and find out which objects in the map were written but not committed.
e.g. map.put("foo", "bar");
// system crashes...
// ...later that same day...
String bar = getLogFile().getMap().get("foo");
in general, i can't find anything about accessing & controlling the log file - any help appreciated.
I think there's a misconception about the log file. The log file is used to persist changes once they have been committed -- no changes are persisted until you call commit().
The log file stores changes that you want to make to the main database file. When you commit(), the changes are synchronized to disk (in the log file) and are later propagated in the main database file. This two-phase approach is the basis of the transactional guarantee.
If a failure happens after commit(), the log file is "re-played" during recovery and the changes are repeated in the main database file.
There is currently no API to control the log file. All this processing happens behind the scene to simplify the programming task of the client.
ok, i originally thought that the log file was written to *before* commit and then synchronized immediately when commit was called. sort of like a queue of requests to be posted.....i get it now though.
just in case you are curious, the functionality i was looking for was a way to find out what state i was in during a transaction.
step 1 // if something went wrong
step 2 // how do i find out which
step 3 // steps finished?
(i know none of the data will be persisted, but there are other side effects that need to be addressed which require the transaction's state)
thanks for the quick reply & explanation,
I see where you're going. The transaction model supported by JDBM is often referred to as "coordinated", in the sense that all participants are involved in the transaction and agree to that semantic (all or nohting). In such model, there are no side-effects until the transaction commits.
What you are after is a form of extended transaction model where you keep a persistent state of execution after each step of your overall processing. Using a model like this allows for additional processing during recovery since you can determine where you were before failure. You could, for example, compensate for side-effects or resume where you left off depending on what you were doing.
If you are so inclined, this type of extended transaction model can be built on top of JDBM and leverage the existing (lower-level) transaction subsystem.