Details of bundle commit steps

PolicyCenter commits a bundle to save data to the database by performing the following steps.
Note: Bundle commit does not perform the following preupdate rule sets and validation rule sets: archiving, geocoding changes, messaging reply, messaging preprocessor, upgrade actions, and XML import, including administrative data import. For this reason, there are no messaging events nor concurrent data change exceptions for these actions. These actions always overwrite an entity instance in the database with the instance in the bundle.
  1. PolicyCenter reserves a connection from the connection pool.
  2. Internally, PolicyCenter saves the state of the bundle. PolicyCenter uses this snapshot to revert to the current state of data if writing to the database fails.
  3. PolicyCenter runs preupdate rule sets.
  4. PolicyCenter refreshes all entity instances that already existed but are unchanged in the bundle. This action ensures that validation rules, which run next, get the newest versions of those entity instances.
  5. PolicyCenter triggers validation rule sets.
  6. PolicyCenter sets properties that exist on editable and versionable entities: updateTime, createTime, and user.
  7. PolicyCenter increments the version number on each modified entity instance.
  8. Any entity instances that are new (not yet in the database) have a temporary internal ID. An internal ID is the entity.Id property. PolicyCenter creates the permanent internal ID for each new entity instance and assigns the value to the entity.Id property. PolicyCenter sets any foreign key references to refer to the new internal ID value rather than the temporary ID.
  9. PolicyCenter computes the set of new, changed, and removed entity instances in the bundle.
  10. PolicyCenter determines the set of messaging events that are raised by changes in the bundle.
  11. For each messaging destination that is registered to listen for messaging events, PolicyCenter triggers Event Fired rule sets once for each messaging destination. For example, ENTITYNAMEAdded, ENTITYNAMEChanged, or ENTITYNAMERemoved events. If more than one destination listens for the same event, the Event Fired rule set executes once for each messaging destination.
  12. PolicyCenter writes all changed entities to the database connection. During this step, PolicyCenter checks for concurrent data change exceptions.
  13. PolicyCenter attempts to commit the database connection. This action either completely succeeds or fails.
  14. On success, PolicyCenter updates the global entity cache. The global entity cache speeds up entity data access by caching recently used data in memory on each server in a PolicyCenter cluster.

    After updating the cache, the current server signals other servers in the cluster about the change. This signal tells the other servers to remove data from the cache for entity instances that just updated or deleted. After a server receives this signal, entity instances in a remote entity cache immediately show the data as requiring an update, but do not immediately reload data from the database. Any local existing references to the old data on the other servers are out of date and will never commit to the database. The entity data is safe from accidental changes of this type.

See also