Raised as last step of an (successful or failed) Commit operation for any persistent object that was involved in the operation.
Notifies the subscriber that sender has been committed into the corresponding DataDomain. The value of CommitResults indicates the success status of the operation. A value of CommitResults.Committed indicates that the logical transaction (and all physical database transactions) has been committed successfully. Any change performed in the same Context initiates a new logical transaction. A value of CommitResults.CommitFailed indicates that an error has occured during the call to Commit. In such cases the logical transaction remains open and any changes performed in the same Context continues the existing transaction.
The event is raised after the update batch has executed and all AfterUpdateObject events have been processed. The AfterCommitObject event is raised for all persistent objects that have been involved in the current logical transaction of the Context however the order in which individual persistent object are notified is indeterministic.
The subscriber of this event may freely modify sender or any other persistent objects however doing so will initiate a new logical transaction. Thus changes performed in the AfterCommitObject event will be saved only at the next call to Commit.
The value CommitResults.Rollback has been deprecated, as the AfterCommit events are not fired anymore for a rollback operation. To perform actions before/after rollback, the BeforeRollback and AfterRollback events can be used.
Events raised by the Context can be captured from different areas of interest. The developer may choose to capture a certain event originating from a certain Context by subscribing to one of the Context events using the standard .NET event mechanism. This allows for multiple queued event processors and dynamic strategies in handling events. The order in which subscribers are notified is nondeterministic and hence no subscriber should perform operations with side-effects that would affect the execution of other subscribers or that assumes a certain execution order. This way of processing Context events is similar to handling events raised by ADO.NET DataTable.
The developer might optionally choose to process Context events on persistent objects directly. In this case the class implementing persistency should be inherited from the corresponding callback interface. Each callback interface defines one method to implement with a similar signature as the corresponding event delegate. When the Context raises an event for a persistent object it executes the callback method whenever the object implements the appropriate callback interface. This practically ensures that the object is always subscribed to all events of any Context that it is interested in regardless of how the Context itself is configured by the caller.
The Context that raises the event will automatically become the active Context in the calling thread for the duration of the call. This ensures that any unbound proxies used in the event handlers are resolved from the relevant Context. When the events have been successfully processed, the context stack of the calling thread is restored to its previous state.
Assembly: TechTalk.Genome (in TechTalk.Genome.dll)
Editions: Professional, Evaluation, Express