TechTalk Genome v4.2

Context.ChangeObject Event

Raised before the first change is made to a persistent object in this Context.

public event ObjectEventHandler ChangeObject;




Signals that sender is about to get into unsynchronized state in the given Context. A persistent object is unsynchronized in a Context when pending, uncommitted changes have been made to it. The state of unsynchronized persistent objects resides in the Transactional State Buffer of the Context. When changes are committed using Commit or aborted using Rollback all committed persistent objects get back to synchronized state.

The ChangeObject event is raised before the first uncommitted change would execute on the given object. A persistent object can be changed either by modifying any of its persistent properties, or by deleting it using any of the Delete or DeleteCurrent methods. The ChangeObject event is not raised for persistent objects created by the DataDomain.New method.

The ChangeObject event is raised only once within each logical transaction of the Context. Subscribers of the event are free to modify any related persistent objects or even the sender itself without running into infinite recursion issues. The event is not fired when a persistent object has been already manually enlisted into the Transactional State Buffer of the Context using the MemoryLock method.

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.


Namespace: TechTalk.Genome

Assembly: TechTalk.Genome (in TechTalk.Genome.dll)


Editions: Professional, Evaluation, Express

See Also

Context Class | TechTalk.Genome Namespace | IChangeCallback | Change | DeleteObject | LoadObject