What you may need to know about DBTransaction::postChanges()
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