TechTalk Genome v4.2

LocalContext Class

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 LocalContext Members.


public abstract sealed class LocalContext


New instances of the Context class can be created by using one of the predefined context factory classes: LocalContext, ShortRunningTransactionContext and ReadOnlyContext.

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 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.


Namespace: TechTalk.Genome

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

See Also

LocalContext Members | TechTalk.Genome Namespace