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.
OP_OPTIMISTIC - If this option is set to True, optimistic checkout semantics are enabled. This option must be set at view checkout time and at view checkin time so that a baseline copy of the view can be taken and optimistic reprovisioning can occur. This baseline copy of the view is used during the subsequent view checkin to determine any intervening changes that may have occurred to the same User by other Update User workflow reprovisioning operations. These intervening changes, if any, are compared against the local changes to determine if any conflicts are present and, if not, to merge the local changes with the intervening remote changes to complete the reprovisioning process for that User.
OP_OPTIMISTIC_RETRY_COUNT - The number of times a caller can to retry a reprovisioning operation. The default value is 3 times.
The reprovisioning operation attempts to lock the User repository object and ensures that no pessimistic Update User workflow is running for the same User before performing optimistic reprovisioning. If either of these conditions are not met, the task retries after sleeping for the specified interval. If the retry count is exceeded, an exception is thrown.
OP_OPTIMISTIC_RETRY_INTERVAL - The number of milliseconds to wait between reprovisioning retries. The default value is 30,000 milliseconds (30 seconds).
OP_IGNORE_CONFLICTS - This view option can be passed at user view checkin time to force the local changes to be committed. If it is set and evaluates to True, then the reprovisioning behaves in an optimistic manner with the exception that conflicts, if found, are not considered an error. Merging is still performed with local change values being committed in cases of conflict, thus overwriting these conflicting intervening changes. Non-conflicting changes are preserved. In the case where no other errors occurred but conflicts were found and OP_IGNORE_CONFLICTS is set to true, the WavesetResult will contain a named result (called conflicts) but will not have an error result set.
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"); }