A user writes in to ask, "Can you please explain what happens at the database and the ADF level each time I do a New, Update, or Delete operation?"
The JDeveloper online documentation contains a topic about ADF Business Components Cache Management and a number of related topics that explain this, but I'll try to syntehesize.
At the ADF binding layer, you are working with rows in a collection. When you use the ADF binding layer with ADF Business Components as your business tier implementation stack, this collection is a ViewObject's rowset containing view object rows. Those view rows are related to underlying entity object usages in their metadata if the view object is designed to allow creates, updates, and removes. If there are no entity objects related to a view object, then it's a read-only data source. The view object uses it's entity usage metadata to delegate all operations like create, remove, and attribute modifications down to the appropriate underlying entity instances in the cache. It is the entity instance that manages saving its changes back to the database in the form of INSERT, UPDATE, or DELETE "persistence" operations when the time is right. Until that time, the changes are just in the ADF entity object's entity cache in memory. By default, the uncommited modifications to entity caches are saved for you in a kind of XML-based "redo log" of sorts, that the ADF application module's state management feature handles for you. (See this article, for more information on our state management feature if curious).
The ADF binding layer's action bindings operate on ADF iterators in a generic way, so in action bindings like "Create" and "Remove" end up calling underlying view object rowset methods like createRow(), insertRow() as well as the remove() method on a view row to remove it as appropriate. Any attribute modifications that are applied to the model by the ADF binding layer, end up setting the view row attributes under the covers, of the appropriate row. In turn, these attribute sets are delegated to the entity cache for any view row attributes that are related to an entity usage.
If you are working with locking mode = PESSIMISTIC, which is the default but not the recommended setting for web applications, then when you update the first persistent attribute or remove an entity object, it will be immediately locked. Generally developers use locking mode = OPTIMISTIC our web applications to avoid having any locked rows until commit time.
Regardless of locking mode, when you create a new row, no database operation occurs immediately.
Other than the note about pessimistic locking above, all DML operations occur to save the changes you've made to any new, removed, or modified entity object instances when the entities are asked to post themselves to the database. This will occur as part of calling commit() on the transaction. You can also make it occur without committing by calling postChanges(), but the use of postChanges() outside of methods firing as part of a commit cycle is not recommended for use in web applications. This is the case, in brief, since for application module pooling to operate most efficiently, it cannot guarantee that posted-but-not-committed changes in the current JDBC transaction will still be there on the next HTTP request. This is tue to the fact that your request might get served by a totally different AM instance from the AM pool (and its totally different JDBC connection).
When an entity is asked to post itself, eventually it's prepareForDML() and doDML() methods are called by the framework and by default it does the appropriate INSERT, UPDATE, or DELETE needed to save the change permanently in the database.
1:11:43 PM 
|
|
