Why You Don't Want to Code Validation in Before Commit

You should know by now - there are many things possible in ADF, but it doesn't mean every solution is right, even if it works. One example of such case - coding validation rules in beforeCommit method. This method is invoked after all changes are posted and ADF BC assumes data is valid, if we throw later validation error from beforeCommit - ADF BC state remains unchanged and changed data is not submitted again. There is a workaround to set jbo.txn.handleafterpostexc=true and to force in memory passivation snapshot with subsequent activation on validation error - however, this is a big performance hit. Every time, where there will be validation error - rollback will be executed and entire AM with all VO instances will be re-activated (SQL re-executed and data re-fetched). Today post is about bad practice, to demonstrate why you should not code validation in beforeCommit method.

Sample application - ADFHandleAfterPostApp.zip, implements validation rule in EO beforeCommit method. Validation rule calls PL/SQL function and throws exception if validation result is false. It validated salary value from the current row (PL/SQL function code is attached in sample application):

PL/SQL function checks if salary value is lower than 2000:

Sample application is configured with DB pooling. By default, without DB pooling set - DB lock will not be removed after exception from beforeCommit:

To test beforeCommit validation behaviour, open the form and set Salary value below 2000. Change also another field - FirstName, for example:

As expected, there will be validation error and exception thrown - error message displayed:

We can see the sequence of steps happening in the log. There is DB lock for the current row, data is posted successfully for both Salary and FirstName attributes, then exception happens:

Ok, we can fix Salary attribute value and set it to be higher than 2000. Keep the same value for FirstName attribute, it is not committed yet to DB and we expect it to be committed now:

What we can see in the log now - Salary attribute value was posted and committed, as validation passed successfully. However, second changed attribute - FirstName, value was not committed. This is because, ADF BC thinks FirstName was committed during previous commit, when it actually failed. As exception was thrown in beforeCommit, this is already after ADF BC marks data as valid and assumes to be committed to DB. This is the main issue with coding validation in beforeCommit - ADF BC transaction state remains invalid:

If you press Rollback - you will see, FirstName will be reset to the previous value:

There is a workaround for this case, to use jbo.txn.handleafterpostexc = true property in AM configuration:

However, this leads to runtime performance issues - as it fires passivation in memory on each commit and does rollback with re-activation on every validation error in beforeCommit. We can track all such activations, fired from beforeCommit, by overriding activateStateForUndo method in AM:

We can test the same scenario - change LastName and Salary attributes, set Salary to be less than 2000:

Now we can spot - there was activation event raised:

During activation, all VO's are re-executed and re-fetched. Here we can see SQL query and data fetch for Employees:

There is SQL query and data fetch for Departments, even we didn't touch it: