In some specific use case scenarios both entity objects and stored procedures may need to co exist in your business logic implementation. This may arise if you are migrating(replacing) existing applications with ADF based application, and your customer wants to reuse some pieces from the legacy application. When you start identifying reusable pieces, in most of the cases, all eyes may be on stored procedures - we may need to accept the realities ;). As the data update logic is scattered across entity objects and stored procedure you may end up in calling DBTransaction::postChanges() to post the entity changes to data base before invoking stored procedure. Usage of DBTransaction::postChanges() is permitted if you commit the transaction within the same request. However there are some points you may need to aware of to make your implementation more perfect.
To understand the DBTransaction::postChanges(), let us take step back and analyze the transaction commit cycle first. Consider a typical use case , where you have modified entity data, and finally you call DBTransaction::commit () to commit the transaction.
The sequence of actions that happens behind the transaction commit cycle are as follows:
The DBTransactionImpl calls...
DBTransactionImpl maintains 3 lists to carry out the commit cycle. 1. validation listener list 2. transaction post listener list 3.transaction listener list. When you dirty an EO instance, it will get added to these three lists. If you call DBTransaction::postChanges(), step 4 alone gets executed from the above sequence and this operation clears transaction post listener list alone. In nutshell EOs will remain attached to the validate/transaction listener list till you call commit. This may have some side effect in certain scenarios.
In case if you need to invoke postChanges() multiple times, you can manually clear the above said lists as shown in the following code snippet
To understand the DBTransaction::postChanges(), let us take step back and analyze the transaction commit cycle first. Consider a typical use case , where you have modified entity data, and finally you call DBTransaction::commit () to commit the transaction.
The sequence of actions that happens behind the transaction commit cycle are as follows:
The DBTransactionImpl calls...
- applicationModule::beforeCommit()
- validate for each entry in validation listener list ( this in turn validates each EO )
- applicationModule::afterCommit()
- postChanges() on each entry in transaction post listener list
- beforeCommit for each entry in transaction listener list
- commit transaction
- afterCommit() for each entry in transaction listener list - EO/VO cache is cleared based on the configurations.
DBTransactionImpl maintains 3 lists to carry out the commit cycle. 1. validation listener list 2. transaction post listener list 3.transaction listener list. When you dirty an EO instance, it will get added to these three lists. If you call DBTransaction::postChanges(), step 4 alone gets executed from the above sequence and this operation clears transaction post listener list alone. In nutshell EOs will remain attached to the validate/transaction listener list till you call commit. This may have some side effect in certain scenarios.
In case if you need to invoke postChanges() multiple times, you can manually clear the above said lists as shown in the following code snippet
// Get VewRowImpl someVewRowImpl from VO
someVewRowImpl.setAttribute( "SomeAttrib","New Value");
EntityImpl someEOImpl = someVewRowImpl.getEntity(0);
DBTransaction txn = getDBTransaction();
txn.validate();
txn.postChanges();
txn.removeTransactionPostListener(someEOImpl);
//The below two lines may cause your EO to skip
// beforeCommit() and afterCommit() call backs.
//Normally you can skip the below two lines,
// use it if you need to clear the EO cache once data is posted to DB
// This makes sense if you have millions of rows in an update and
// and you want to get rid of the cached rows without any delay
txn.removeTransactionListener(someEOImpl);
txn.clearEntityCache(null); 
