When you want to provide each session (each user) with its own access layer stack, you configure your application to use multiple object store coordinators. Specifically, you give each session its own object store coordinator. Doing this also instruments concurrency in your application, so it should be done with caution. See “Providing Separate Stacks” to learn how to provide each session with its own object store coordinator.
If possible, all users of an application should share an object store coordinator. This is the default behavior (that all editing contexts in a particular application instance share the same object store coordinator) and it helps you avoid and deal with update conflicts caused by multiple users editing the same row or rows of data concurrently.
There are reasons, however, why you would want to provide each user with a separate access layer stack. One of the more common reasons is to provide an audit trail in an application. A crucial part of any audit trail is tracking access to data sources. When you provide each user with a separate access layer stack, you can then use different credentials to establish the database connection, provided that you make the connection programmatically. This is discussed in “Connecting to a Database” in the section “Storing in Code.”
Note: Applications that use multiple object store coordinators consume more memory than applications that use only one because each coordinator contains its own set of row-level snapshots and other data about the enterprise objects they fetch and manage.
Last updated: 2007-07-11