Concurrent data change prevention

It is possible for different users, either on the same PolicyCenter server or on a different server, to attempt to change data objects concurrently. To prevent data corruption, Guidewire implements a data object versioning mechanism. During the update to an object value to the database, PolicyCenter compares a counter associated with the object to the counter in the database. A counter value mismatch indicates that two different user changed the object concurrently. In such case, PolicyCenter rejects the change and the cache mechanism throws a concurrent data change exception. PolicyCenter presents the user who initiated the concurrent change with the error and reloads the latest data. The user can then reapply the changes.

Furthermore, PolicyCenter commits changes in an atomic bundle, ensuring transactional integrity. Therefore, PolicyCenter enforces protection against concurrent data changes across the whole transaction. This mechanism is a standard design pattern called optimistic locking.

Concurrent data change exceptions occur only if two users modify the same object. A proper organization of the user community avoids this. Nevertheless, if two users modify the same object, any automatic resolution carries a significant risk of causing unwanted modifications. The optimistic locking mechanism causes very few concurrent data change exceptions and users can easily resolve those exceptions.

Other design patterns exist for concurrent data changes. The pessimistic locking pattern prevents all other users from modifying an object while one user or batch process is making a change. In many cases, pessimistic locking becomes completely dysfunctional. For example, if a user or batch process cannot complete a change, the locking mechanism blocks any other user of batch process from making a change. Pessimistic locking systems generally become impractical. Therefore, PolicyCenter uses the optimistic locking mechanism.