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 newly created Context instance.
The created Context
When a Context is configured for short running transaction behaviour, changes done to persistent objects are continuously updated into the database using physical database transactions. The changes will be collected as much as it is possible while retaining maximum transaction consistency and the updates will be performed in short bursts.
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. At the same time, a new physical database transaction is automatically started in the corresponding DataDomain if such transaction was not already open in the given Context. The created database transaction is kept open until the logical transaction of the Context is either committed or aborted.
The physical database transaction created in the Context will use the default isolation level of the database server (IsolationLevel.ReadCommitted) and it will be created on the first read operation.
Although ADO.NET transactions can be attached only to one database connection, Genome can handle parallel enumerations (e.g. nested loops enumerating sets) in the same Context even after the physical database transaction has been started. If a query has to be executed but the connection is still busy with processing another query, Genome finishes the first query by loading up the result to a temporary store and starts executing the requested query. If further records are read from the prefetched query they will be fulfilled using the temporary store.
Whenever a Set query is made in the Context all pending persistent objects are saved into their respective DataDomains using the open physical database transactions before the query would be evaluated. This behaviour ensures that the query results are consistent with the Transaction State Buffer. The isolation level of the physical database transaction determines how these intermediate updates will affect callers of other AppDomains or Contexts. A Context.BeforeUpdateObject and Context.AfterUpdateObject even pair is raised for every persistent object involved in this update batch. This update batch is performed any time a Set query is made in the Context that has updated persistent objects in its Transactional State Buffer. This also means, that the same persistent object might be saved into its DataDomain many times before the transaction is committed. Genome will raise a Context.BeforeUpdateObject and Context.AfterUpdateObject even in all occasions.
When the transaction is committed using Context.Commit a Context.BeforeCommitObject event is raised for all persistent objects that have been modified in this transaction (since the last call to Context.Commit or Context.Rollback) even if the concerned persisten object has been already saved to the DataDomain in an earlier update batch. If there are any unsaved persistent object in the Transaction State Buffer those are saved in a similar update batch as described above. After all affected persistent objects are saved into their DataDomains all physical database transactions are committed and an Context.AfterCommitObject event is raised for all involved persistent objects signaling the success of the operation with either a CommitResults.Committed or CommitResults.CommitFailed value.
When a short running transaction is aborted by calling Context.Rollback all open physical transactions are rolled back and the Transaction State Buffer of the Context is discarded. A Context.AfterCommitObject event is raised for all changed persistent object that is being removed from the Transactional State Buffer.
As contexts configured to use short running transaction model update the databases before evaluating any Set queries it is ensured that always the most current version of each persistent object is investigated in filter critera, order clauses and selector expressions hence consistent results are returned. It is important to notice however, that Genome can update persistent objects only in their consistent state. It is therefore not recommended to execute queries in constructor body of persistent objects before the identity of the new object would be established.
Due to its consistency advantages short running transactions are recommended in scenarios where persistent objects are intensely modified and then requeried. Since short running transactions do not provide any additional performance benefit in terms of server side resources the same performance considerations should be taken as when using T-SQL transactions or SqlTransactions. Hence short running transactions should be rather used in uninterrupted batch update scenarios.
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, Express
ShortRunningTransactionContext Class | TechTalk.Genome Namespace | ShortRunningTransactionContext.Create Overload List