Checkpointing
makes cross-entity undo
a snap. It's usually a nasty business
to track and undo changes when the
user cancels out of a dialog or wizard,
especially if there are many different
business objects in play. Now we just
set a checkpoint when the dialog begins
and turn the user loose. If the dialog
ends happily, we discard the checkpoint.
If the user cancels, we rollback. Either
way, it's one call to start and one
call to finish. No bookkeeping required.
We can stack checkpoints with additional
BeginCheckpoint() calls. Each subsequent
RollbackCheckpoint() undoes the most
recent checkpoint. We can cut back
the stack by calling RollbackCheckpoint(count)
where "count" is the number of checkpoints
to rollback. Both overloads return
the remaining checkpoint depth.
The RollbackCheckpoints() method rolls
all the way back while ClearCheckpoints()
wipes the checkpoint slate clean. ClearCheckpoints()
is kind of like “commit” in that we
are accepting the present state of
the entity cache. But take care: our
pending changes are still in the cache;
they won't become permanent until we
save them to the database!
Note also
that the PersistenceManager's Clear()
and SaveChanges() methods call ClearCheckpoints()
automatically before proceeding with
their respective tasks.
Checkpointing is lightweight. A checkpoint
session records changes to the cache
- not images of the cache. Clearing
checkpoints to accept changes is virtually
instantaneous; rollbacks, which are
comparatively rare, are very fast. |