Providing Separate Stacks
To provide each user of an application with an independent access layer stack, you provide each user with a separate object store coordinator. As described in “The Access-Control Divide” and “Object Store Coordinator,” an EOObjectStoreCoordinator is the highest-level object in the access layer stack. Each object store coordinator instance, then, represents a single database connection to each of the cooperating object stores registered with it.
The editing contexts that share an object store coordinator share a single database connection. Editing contexts that use different object store coordinators can perform concurrent operations to the same database. So if user A performs a fetch, user B can perform a commit concurrently.
To provide each user with an individual object store coordinator, you instantiate a new EOObjectStoreCoordinator, instantiate a new EOEditingContext whose parent is the new EOObjectStoreCoordinator, and set a session’s default editing context to be the new editing context whose parent is the new object store coordinator. This can be done programmatically in a Session class using the code in “Listing 5-1.”
Listing 4-1 Providing separate object store coordinators
public class Session extends WOSession { |
public Session() { |
super(); |
/* Provide each session with its own access layer stack. */ |
EOObjectStoreCoordinator parentObjectStore = new EOObjectStoreCoordinator(); |
EOEditingContext editingContext = new EOEditingContext(parentObjectStore); |
setDefaultEditingContext(editingContext); |
} |
} |
A common reason to provide each user with a separate stack is to provide each user with a separate connection to the database. If you need to do this, you also need to set values in the connection dictionary for each user. This is discussed in “Providing a Connection Dictionary in Code.”
The objects in an Enterprise Objects application using a separate object store coordinator per session are illustrated in “Figure 5-3.”
When you provide separate object store coordinators to each session, you must adopt a different set of assumptions about how the object graph works. When you provide each session with its own access layer stack, you provide each session with a separate EODatabaseContext, which means that sessions no longer share row-level snapshots—they have entirely separate row-level snapshots. Since row-level snapshots are an integral part of Enterprise Object’s optimistic locking mechanism, you must reconsider the locking strategies you implement. This and other related issues are discussed in “Multiple Coordinators and Optimistic Locking.”
Last updated: 2007-07-11
  |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |