Windchill's multi-object API infrastructure support makes it possible to perform an operation against a collection of objects without resorting to looping somewhere in the process to persist the changes, call other APIs, or dispatch events. This reduces the number of trips to the database and the number of method calls: an operation to persist 100 objects can call the database once (using a batch operation) and dispatch, again once, the events pertinent to the operation. Similarly, the event listeners can operate against the entire collection, replacing duplicative persistence (CRUD2) operations with multi-object operations that hit the database as little as one time (as opposed to n times). The multi-object API should significantly outperform the looping equivalent even when the collection has only one element, as event listeners to copy associations, etc., can benefit from the multi-object APIs. Windchill's support for multi-object APIs consists of:

Windchill-specific collections utilize the Java Collections framework to provide sets, lists, and maps optimized for Windchill persistent objects. These collections seamlessly handle Persistables represented as QueryKeys, WTReferences, and fully-inflated Persistables. The collections also provide numerous APIs for doing things such as refreshing and inflating, getting sub-collections based on class, and testing membership. See the wt.fc.collections package in the Javadoc for more information.

Multi-object event dispatch and notification allows any event (such as PRE_STORE) to be dispatched and notified as either single- or multi-object. The event mechanism automatically handles the case where the dispatcher and notifier (that is, the listener) are inconsistent by converting the multi-object event into single-object events and looping over the listener and, vice-versa, by converting the single-object event into a multi-object event and notifying the multi-object listener. Multi-object events will have collections-based event targets.

Multi-object delegationmakes it possible to request the delegates for a collection of objects. The multi-object delegate APIs will then map the appropriate delegates to sub-collections of the collection that would use them. It is then possible to execute multi-object APIs on the delegate, passing these sub- collections to the delegate's multi-object APIs. For example, when requesting the "x.y.Z" delegate for a collection of parts and documents, the result may be that delegate1 matches the parts and delegate2 the documents; delegate1's multi-object API can then be called, passing the parts sub-collection. See the Javadoc entry for wt.services.ac.DefaultServices for more information.

Multi-object exceptions are thrown by multi-object APIs and listeners. These exceptions provide extended information about the nature of the problem(s) associated with some of the objects in the passed-in collection. For example, if a change identity against ten objects failed because three of the objects were assigned non-unique identities, the resultant exception will indicate the three individual failures. This is made possible by the addition of "additionalMessages" to wt.util.WTException.

Multi-object CRUD persistence manager APIs interact with the database using batch operations, reducing the total number of database interactions for a CRUD operation to as little as one (more practically, as little as one per table). A "store" operation passing a collection of 100 parts can employ a single bulk insert to the database, rather than 100 individual insert operations. See the wt.fc Javadoc entry for more information.

Batch ("UPDATE WHERE" and "DELETE FROM") statement capabilities produce Windchill statements that, in the database, are translated as UPDATE WHERE and DELETE FROM statements. This makes it possible, for example, to delete all of the associations for a collection of objects in one database hit without even requiring the links to be pre-queried (in practice, these operations are still subject to events, so the OIDs may be returned and, if the listeners require full persistables, inflated). See wt.fc.batch for more information.

Transaction context and listeners provide fine-grained mechanisms for adding information to the nested and global transactions (in a manner similar to the MethodContext) and for being notified when a transaction is about to commit, has committed, or rolls back. See the Javadoc entries for Transaction, TransactionListener, and TransactionCommitListener in the wt.pom package.

Referential integrity association validation during object delete employs a declarative mechanism to specify how associations should behave during deletion. Each role can indicate that, when the role object is being deleted, the association should be deleted or the deletion vetoed.