What you may need to know about DBTransaction::postChanges()
2011-11-01 10:25
585 查看
原文: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 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
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...
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);
相关文章推荐
- What you need to know about AllowUnsafeUpdates (Part 2) [转载]
- What is LineageOS ? Everything you need to know about Lineage OS
- WCF Essentials - What You Need To Know About One-Way Calls, Callbacks, And Events
- What you may need to know while calling Application Module methods from Java EE components such as E
- DB2 System Catalog Views: Everything You Need to Know About Your DB Objects
- What you need to know about transimpedance amplifiers – part 1
- 转 译文:你需要知道的CSS3 动画技术 译自:What You Need To Know About Behavioral CSS
- [转]What you need to know about transimpedance amplifiers – part 1
- What you need to know about AllowUnsafeUpdates (Part 1) [转载]
- The 9 Deep Learning Papers You Need To Know About
- What programmers need to know about hardware prefetching?
- Everything you need to know about Authenticode Code Signing
- All you need to know about tethering with your Android device
- 50 Kick-Ass Websites You Need to Know About
- Something you need to know about Content Deployment in SharePoint
- Something you need to know about Objective-C and iOS programming: for experienced programmers
- Something you need to know about INITIALIZATION LISTS in Constructor of C++
- 10 Things You Need To Know About Cocoa Auto Layout
- The 9 Deep Learning Papers You Need To Know About (Understanding CNNs Part 3)
- 100 Things You Need to Know about Microsoft Windows Vista