This area of Genome is subject to change.
Creates a new Context instance that can be used to encapsulate access to all DataDomains in the calling AppDomain. The created Context will be inherited from the specified Context, will use the specified LockingSemanticsBindings for locking, will have a caching behavior governed by the specified CacheConfiguration and will have a default data retrieval behavior defined by the specified DataRetrievalConfiguration.The newly created Context instance.
The created Context
When a Context is configured for long running transaction behaviour, all changes done to persistent objects in that context will be retained until the next call to Context.Commit. Whenever a field of a persistent object is changed, that object will be fully loaded into the Transactional State Buffer and changes made to that object will be logged there. Unless the object is locked using Context.Lock method other threads and AppDomains can freely modify it.
When the transaction is committed using Context.Commit, a new physical database transaction is started in all DataDomains that have pending changes in that context and all pending objects are updated in the context of its respective database transaction. Before any updates would take place a Context.BeforeCommitObject and Context.BeforeUpdateObject event pair is raised for all concerned persistent objects. Only after all changes in all concerned DataDomains are successfully updated are the physical database transactions committed. Before commiting the trasnactions a Context.AfterUpdateObject event is raised for all persistent objects that have been updated. If any of the changes are unsuccesfull, all database transactions are rolled back. In any case a Context.AfterCommitObject event is raised signaling the success of the operation with either a CommitResults.Committed or CommitResults.CommitFailed value.
When a long running tranaction is aborted by calling Context.Rollback the Transaction State Buffer of the Context is emptied. As no physical database transactions will be started by Genome a rollback operation of a long running transaction will always succeed. A Context.AfterCommitObject event with CommitResults.Rollback value will be raised for all persistent objects affected by the current transaction.
As contexts configured for long running transaction behaviour create physical database transaction for short bursts of object updates only they can be safely kept open for longer periods of time. This nature makes long running transactions ideal for user interaction scenarios where changes made by the end-user are to be collected accross several web requests or WinForms events.
Since Genome uses only the database to populate elements of any Set query, uncommitted changes will not be reflected. Elements returned by such queries will be selected using the original version of those objects as seen in the database. When a newer version of an object is found in the database, the object is invalidated from the caches of the active Context and repopulated. Although objects in the Transactional State Buffer are not invalidated, even if the DataDomain contains an updated version, still the updated version is used to evaluate query filter criteria, order clauses and selector expressions. In certain queries this can cause inconsistency anomalies, such as an object that does not conform to the filter clause or objects in inappropriate order might be returned from a query. If a higher level of consistency is required ShortRunningTransactionContext is to be used.
The returned Context instance will not automatically become the active Context in the calling thread. Use Context.Set or Context.Push to utilize the new Context instance in the calling thread.
Namespace: TechTalk.Genome
Assembly: TechTalk.Genome (in TechTalk.Genome.dll)
Version: 4.2.4.4
Editions: Professional, Evaluation
LocalContext Class | TechTalk.Genome Namespace | LocalContext.Create Overload List