This project is read-only.

NPersist Feature Guide: Consistent Commits

NPersist Feature Guide

Using default settings, when asking the NPersist context object to commit the changes in its unit of work to the database (insert new objects, update modified objects and delete removed objects) a local database transaction will encapsulate the operation.

This means that should the commit operation fail halfway through, all changes to the database will be rolled back so the database is left in the same state as it was in before the operation was attempted, protecting it from containing the results of half-committed units of work.

That’s good for the database, but what about the in-memory objects? Will half the objects think they have been committed to the database now (although they haven’t because their insertions, updates or deletes were rolled back)?

If so, trying to commit again after fixing the error that caused the first attempt to fail would result in only the second half of the unit of work to be saved to the database, since the first half thought it had already been saved.

This is of course undesirable, so NPersist ensures that a failed commit operation will also roll back all changes to the in-memory objects, so that no objects think they have been saved when in fact they have not.

This preservation of the consistency of the in memory object graph is what allows you to keep the context with the unit of work that failed to commit in memory, fix the problems that caused the failure (resolving optimistic concurrency conflicts, handling validation errors and so on) and then simply try to commit again.

Without such preservation of consistency, any failing commit operation would result in a situation where you would have to throw away the context with the user’s changes and go on to ask the user to start over their work.

Last edited Feb 23, 2008 at 5:13 AM by matshelander, version 3

Comments

No comments yet.