Scenario: Lets say i have 2 tables bound to 2 Different VOs[EO Based] which allow editing of data. After Editing of the data on both the tables , i call commit on the Data control Frame.
Now my understanding of AM is that it's a unit of work which is a collective representation of a functionality [let's say , Create PO].
So can there be a scenario that while processing commit , changes performed on one EO gets committed to the Database and the second EO threw some error , so the changes for second EO didn't go thru .
Or this scenario itself is hypothetical and if any of the VOs associated with AM threw error while committing data [not validating], rest of the committed data will also be deleted by framework .
Kindly explain or point to a resource on how multiple VOs would be handled by AM while committing .
Solution: A single AM contains the EO caches for changed rows. Strictly speaking, tables are not bound to VOs they are bound to EOs. VOs do not commit work. VOs describe the shape of the data and the query required for retrieving the data, which is then cached in the EO cache. Basically, if one commits an AM, all "dirty" EOs are validated and if they pass validation, are committed. If any rollback, they all rollback. This behavior can be changed by, for example, having separate AMs.
Now my understanding of AM is that it's a unit of work which is a collective representation of a functionality [let's say , Create PO].
So can there be a scenario that while processing commit , changes performed on one EO gets committed to the Database and the second EO threw some error , so the changes for second EO didn't go thru .
Or this scenario itself is hypothetical and if any of the VOs associated with AM threw error while committing data [not validating], rest of the committed data will also be deleted by framework .
Kindly explain or point to a resource on how multiple VOs would be handled by AM while committing .
Solution: A single AM contains the EO caches for changed rows. Strictly speaking, tables are not bound to VOs they are bound to EOs. VOs do not commit work. VOs describe the shape of the data and the query required for retrieving the data, which is then cached in the EO cache. Basically, if one commits an AM, all "dirty" EOs are validated and if they pass validation, are committed. If any rollback, they all rollback. This behavior can be changed by, for example, having separate AMs.
No comments:
Post a Comment