test

Oracle Waveset 8.1.1 Deployment Guide

Chapter 11 Optimistic Checkouts

By default, Waveset workflow locks User objects pessimistically. This means that Waveset assumes that any concurrent change to the same User object is likely to conflict. Therefore, to prevent overwriting (and losing) previous changes, Waveset first locks the User object when the User View is checked out thus preventing concurrent edits to the same user. It then also ensures that only one Update User workflow is allowed to launch for a given user when the User View is checked in. Taken together, these two mechanisms define the current pessimistic approach to updating users in Waveset.

This pessimistic assumption is the safest course, but this behavior limits the throughput of change operations for a particular User object. It would be desirable for Waveset to allow non-overlapping sets of changes to proceed independently. For example, it might be preferable to allow an ActiveSync process to change resource account information for a User object while another workflow that changes the roles for the same User object is still going through approvals.

A common use case is the scenario where changes to each User are segmented by target resource and are thus largely independent of one another. A change to one resource account for a User object should not block a change to another resource account for the same User.

Optimistic checkout addresses these issues by allowing checkout and checkin of the User view concurrently without locking the user repository object at view checkout time. It also allows multiple Update User workflows to run concurrently. At the time User account reprovisioning occurs, any changes made in the currently executing workflow are checked against “remote” changes that have occurred to the User view since the time the view was checked out. If conflicts are detected, an exception is thrown. If no conflicts are detected, the local changes are merged with the remote changes and committed.

Principles of Optimistic Checkouts

The following principles apply to optimistic checkout:

Detecting Conflicts

Conflict detection is based on the existing UpdateViewer change detection code. This code collects changes to the user view for each account assigned to the user. It also detects changes to a set of hardcoded attributes in the waveset view and also to extended attributes. The list of hardcoded updatable waveset attributes includes:

Constants.ACCOUNT_ID
Constants.PASSWORD
Constants.EMAIL
"disabled"
"locked"
"lockExpiry"
"questionLocked"
"questionLockExpiry"
"correlationKey"
"passwordExpiry"
"passwordExpiryWarning"
"organization"
"roleInfos"
"applications"
"resources"
"resourceAssignments"
"exclusions"
"assignedLhPolicy"
"adminRoles"
"capabilities"
"controlledOrganizations"
"userForm"
"viewUserForm"
"customForm"
"forwardingApprover"
"questions"
"suppliedQuestions"
"idmManager"
"delegates"

In the Administrator interface, such changes to these User view attributes are detected by the existing UpdateViewer and presented to the administrator for confirmation when the Save button is pressed. It appears as a list of attribute names with corresponding old and new values.

Conflict detection for optimistic checkout is based on the UpdateViewer update view and proceeds as follows:

  1. The list of local changes is fetched from the view. The UpdateViewer has already calculated this change list, and it is present in the User view.

  2. The list of remote changes is computed by fetching the baseline view stored in the view at checkout time. These changes are compared to a fresh view based on the current repository User object in the same manner as the local changes are computed. A similar change list is produced.

  3. If a changed attribute appears in either the local or remote changes but not both, then no conflict is indicated.

  4. If a changed attribute appears in both the local and remote changes and has the same new value in both, then no conflict is indicated. This comparison is straightforward for attributes whose values are not lists. However, attributes that contain lists are processed differently, depending on the type of list.

The following types of lists need to be considered when checking for conflicts:

Non-Named GenericObject Lists

Lists composed of elements which are not named GenericObjects never produce a conflict. Since element-level list conflict detection is predicated on the ability to identify list elements (by name) and no such name exists in this case, no conflicts can occur - list order is not significant. As such, for such lists, conflict detection is bypassed. Merging, however, still occurs at the element level.

For example, consider an attribute whose value is a list of strings and whose initial value is [“A”, “B”, “C”]. Then two edits (such as two UserView checkout() methods) occur with this as the starting state for this attribute value. The first edit removes element B, resulting in a final list value of [“A”, “C”] and commits that change. The second edit (an optimistic edit) starts with the same initial value of the list ([“A”, “B”, “C”] but then removes element “A” and adds element “D” giving a local end result attribute value of [“B”, “C”, “D”]. The final merged list value is [“C”, “D”] because:

Lists of Named GenericObject Elements

Assuming named GenericObjects with the same name represent the same object allows for better and more granular conflict detection. Changes in a named element are identifiable since list elements with the same name are assumed to be the same object. In this case, a failing equality comparison indicates a conflict. List additions and deletions are also similarly discernible.

For lists of named GenericObjects, Waveset can detect whether an element has been added, deleted or modified in both the local and remote changes. The system then compares the resulting two lists to determine if a conflict is indicated using the following rules:

Table 11–1 Local and Remote Conflict Checks
 

Local Add 

Local Delete 

Local Change 

Remote Add 

Add conflict is not equal 

   

Remote Delete 

 

No 

Yes 

Remote Change 

 

Yes 

Conflict if not equal 

The blank cells in the table indicate that such a case is not possible. Since the baseline view is the same for computing both local and remote changes, a list addition in one set of changes indicates that the value was not present in the baseline. Therefore, it is not possible to delete or change this (non-existent) element value in the local or remote changes. Similarly, the deletion of an element or change to an element value indicates that the value was present, and an addition of that value is not possible.

An example of such a list that contains named GenericObject elements is the roleinfos attribute. Both the old and new values are lists of objects which are named by the role name. An addition or deletion of such a named element can be determined by querying the list by object name. For cases where the named element is present in the list in both the local and remote changes, the (Generic) objects can be compared for equality. If the new values are identical (equal), then this is not considered a conflict.

Implementing Optimistic Checkouts

The section provides information about the Waveset objects that are used to implement optimistic checkouts.

User View

The UserViewConstants.java file defines the following options to support optimistic checkouts. These can be set as view options when the User View is checked out in the same manner as existing view options.

The following example enables optimistic checkout in a JSP (such as account/modify.jsp):

try {
    String id = requestState.getParameter(requestState, "id");
     if (id == null) {
         form.setTitle(Messages.UI_ACCT_CRT_USR_TITLE);
         form.setViewId("User");
     }
     else {
         form.setTitle(Messages.UI_ACCT_EDIT_USR_TITLE);
         form.setViewId("User:" + id);
  	      // Set this option so that checkin of the view
 	      // won't launch a reprovision.  This does however mean that the user
 	      // changes will be stored.  Need to be able to defer this.
 	      // 	requestState.setOption(UserViewConstants.OP_NO_REPROVISION, "true");

  	      requestState.setOption(UserViewConstants.OP_SELECT_RESOURCES, "true");

 	      // Enable Optimistic Checkout
 	      requestState.setOption(UserViewConstants.OP_OPTIMISTIC, "true");

          // Set this options to true to build the
          // "Forwarding Approvers" select list         
          req.setOption(UserViewConstants.OP_BUILD_APPROVER_LISTS, "true");
     }

Conflict Results Objects

Conflicts, if any, are returned in the WavesetResult returned by WorkflowServices#reProvision() in a named GenericObject called conflicts. This is normally further returned in the GenericObject result from the call to view checkin. This object contains an attribute named accounts which is a list, by account, of attribute conflicts for that account.

For each such conflict detected, a GenericObject representing the conflict is created whose name is the name of the attribute.

The following example shows a set of conflicts.

<Object>
   <Attribute name='accounts'>
     <List>
       <Object name='SimRes1'>
         <Attribute name='conflicts'>
           <List>
             <Object name='attr1'>
               <Attribute name='local' value='Safari Attr1'/>
               <Attribute name='original' value='Orig Attr1'/>
               <Attribute name='remote' value='Firefox Attr1'/>
             </Object>
             <Object name='idmManager'>
               <Attribute name='local' value='Mr. Safari'/>
               <Attribute name='original' value='Mr. Orig'/>
               <Attribute name='remote' value='Mr. Firefox'/>
             </Object>
             <Object name='email'>
               <Attribute name='local' value='safari_email'/>
               <Attribute name='original' value='orig_email'/>
               <Attribute name='remote' value='firefox_email'/>
             </Object>
           </List>
         </Attribute>
       </Object>
       <Object name='Lighthouse'>
         <Attribute name='conflicts'>
           <List>
             <Object name='idmManager'>
               <Attribute name='local' value='Mr. Safari'/>
               <Attribute name='original' value='Mr. Orig'/>
               <Attribute name='remote' value='Mr. Firefox'/>
             </Object>
             <Object name='email'>
               <Attribute name='local' value='safari_email'/>
               <Attribute name='original' value='orig_email'/>
               <Attribute name='remote' value='firefox_email'/>
             </Object>
             <Object>
               <Attribute name='roleInfos'>
                 <List>
                   <Object name='IT Role1'>
                     <Attribute name='local'>
                       <GenericAttribute>
                         <Object>
                           <Attribute name='attribute'>
                             <Object name='IT Role1'>
                               <Attribute name='assignedBy'>
                                 <List>
                                   <String>Business Role 2</String>
                                 </List>
                               </Attribute>
                               <Attribute name='assignmentType' value='required'/>
                               <Attribute name='state' value='assigned'/>
                               <Attribute name='type' value='ITRole'/>
                             </Object>
                           </Attribute>
                         </Object>
                       </GenericAttribute>
                     </Attribute>
                     <Attribute name='original'/>
                     <Attribute name='remote'>
                       <GenericAttribute>
                         <Object>
                           <Attribute name='attribute'>
                             <Object name='IT Role1'>
                               <Attribute name='assignedBy'>
                                 <List>
                                   <String>BusinessRole1</String>
                                 </List>
                               </Attribute>
                               <Attribute name='assignmentType' value='required'/>
                               <Attribute name='state' value='assigned'/>
                               <Attribute name='type' value='ITRole'/>
                             </Object>
                           </Attribute>
                         </Object>
                       </GenericAttribute>
                     </Attribute>
                   </Object>
                 </List>
               </Attribute>
             </Object>
           </List>
         </Attribute>
       </Object>
     </List>
   </Attribute>
 </Object>

In this example, conflicts have been detected in two accounts: SimRes1 and Lighthouse. The attributes on SimRes1 for which conflicts have been detected are attr1, idmManager, and email. For Lighthouse, the attributes in conflict are idmManager, email, and roleInfos. For each conflict the original, remote, and local changed values are listed. The original value is the value of the attribute at the time the view was checked out. The remote value is the value of the attribute present in the repository (or on the resource) at the time reprovisioning started. The local value is the changed value of the attribute made by the currently executing task.

The idmManager attribute had a value of Mr. Orig when the currently running task checked out the User view (the original attribute value). The current task changed that value to Mr. Safari (the local attribute value). However, in the interim, one or more other changes have been committed which changed the attribute value to Mr. Firefox (the remote attribute value). This constitutes a conflict because the remote changes (Mr. Safari) would be lost if the local changes were committed.