This area of Genome is subject to change.Provides factory methods to create new Context instances.
For a list of all members of this type, see ShortRunningTransactionContext Members.
These classes are used to create new preconfigured instances of the Context class that allows the caller to declare different access strategies to be used when retrieving or updating objects in the DataDomains. The following aspects can be configured:
|Cache resource management||Determines the size and the resource management strategy of the cache maintained by the created context. The current implementation supports unmanaged and last-recently-used resource management.|
|Cache invalidation||Determines how objects are invalidated from the cache of the created context. The current implementation supports manual, and timed invalidation strategies.|
|Transaction behaviour||Determines how changed objects are updated into the DataDomain. The current implementation supports long running (LocalContext), short running (ShortRunningTransactionContext) and read-only (ReadOnlyContext) transaction models.|
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 isolation level of the physical database transaction can be configured for the created Context. The default isolation level (IsolationLevel.ReadCommitted) will be used if it is not specified. It is also possible to configure the transaction spawning behaviour using one of the TransactionSpawnMethod values.
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.
Assembly: TechTalk.Genome (in TechTalk.Genome.dll)
Editions: Professional, Evaluation, Express
Database Platforms: Microsoft SQL Server 2000, Microsoft SQL Server 2005, Orcale 9i Release 2, Oracle 10g Release 2