Threading Issues with the Work Item Tracking Object Model

The Work Item Tracking Object Model supports two multithreaded patterns. The first is the One Store per Thread pattern. This pattern scales better because there is no dependency or interlocking between threads. The cost to create a WorkItemStore is high because initialization of a WorkItemStore performs a roundtrip to the backend.

The second multithreaded pattern is the Shared Store pattern, which you can access from multiple threads. Shared Store has no connection cost, and provides instant access. However, it does not scale because access is locked during roundtrips.

There is no support-shared access for other Work Item Object Model objects. There is access only for WorkItemStore and its read-only collections, such as ProjectCollections, NodeCollections, and FieldDefinitionCollections.

One Store per Thread Pattern

One Store per Thread currently is the only scalable pattern. In this pattern, there is no interlocking between objects created from different stores. Thus, there is no interlocking between threads.

The creation cost of the WorkItemStore object is high. Because of this, you should use the One Store per Thread model when you need a multithreaded application. For example, you should use it when you create an ASP.NET application. For efficiency, we recommend you cache the WorkItemStore object in the user session or create a thread-pool of WorkItemStore objects.

Note

The WorkItemStore is thread-agnostic, but it depends on user credentials.

Note

You may need to call the SyncToCache method to update metadata information when the system raises the MetadataChanged event.

Shared Store

Use the Shared Store pattern when you are just accessing metadata, such as Hierarchy, Fields, Projects, Forms, and so on. This metadata is cached locally. A roundtrip to the server will only occur on the first access.

You may also use Shared Store to perform occasional queries or get WorkItem objects. For these tasks, perform all roundtrips sequentially.

Note

WorkItems and query results are not thread-safe.

Metadata Versioning

The WorkItemStore gets a copy of the metadata, created at the time the WorkItemStore was created. Should the metadata change on the client or on the TFS server, the WorkItemStore's copy of the metadata remains unchanged.

This is also true for any pointers obtained from the metadata. For example, if you got a ProjectCollection before the metadata was refreshed, the ProjectCollection points to an old version of the ProjectCollection data.

Versioning the metadata prevents unexpected changes from occurring to the WorkItemStore's metadata.

The MetadataChanged event indicates there is a change in the metadata, and that you can now get a new set of metadata. The system raises the MetadataChanged event when the WorkItemStore does a roundtrip. However, the system does not raise the MetadataChanged event when other WorkItemStore objects that point to the same TFS server perform roundtrips.

Ways to Refresh Metadata

SyncToCache makes sure that the WorkItemStore points to the latest metadata known to the client. SyncToCache does not perform a roundtrip. SyncToCache just tells the WorkItemStore to point to the latest metadata known to the client. This may raise the MetadataChanged event.

RefreshCache updates the client's metadata by making a roundtrip and refreshing all metadata information. RefreshCache is an expensive task. You should not use this call frequently.

See Also

Reference

Performance Tuning the Work Item Tracking Object Model

Metadata Synchronization issues in the Work Item Tracking Object Model