PrepareForDML method called twice

Question

Have implemented a typical scenario (search - add - edit jspx pages).
Within one application module, one view object with dynamically created where criterion is used for searching, and another view object fetching at most one row is used for inserting/updating. The second view object is based on a join of an updatable entity (that has as primary key trigger-generated sequence number) and several referenced readable entities that bring descriptions of the codes of the updatable entity. Have implemented descriptions as output fields in the jspx, settign partialTriggers to the id of the code-field of the updatable entity having autoSubmit=true. Have concentrated business validation logic within the prepareForDML() of the updatable entity implementation.
Under normal conditions, it works fine.
Under heavy system load in production, or testing with ADF State Management enabled at work environment, I observe the prepareForDML() called twice instead of once.
Thus, the first time the insert is commited, the second time the validation rollback, and at last the whole transaction is rollbacked.
When I commented-out all the fields that bring descriptions and set all autoSubmit=false, prepareForDML() was called once.
However, my problem is that I have to bring the descriptions, that result from pop-up windows so that the end-user can see them after selecting sthg on his/er screen.
Why is prepareForDML() called twice, and how can I avoid this?

Answer 1

(2) Can't change the second trigger-assigned field from DBSequence to simply Number since the Entity Object Editor hides the tab Sequence to declare the sequence from which to get this field's value after insert.
Please see section "6.6.3.8 Trigger-Assigned Primary Key Values from a Database Sequence" of the ADF Developer's Guide for Forms/4GL Developers on the ADF Learning Center at http://www.oracle.com/technology/products/adf/learnadf.html for more information on this. The "Sequence" tab doesn't have any runtime behavior influence. The sequence number is not assigned by ADFBC, it is assigned by your trigger. ADFBC only worries about:
1) Providing a temporary unique negative key so that new detail rows can have a temporary foreign key value to point at until the transaction commits
2) Refreshing the entity object's primary key value from the database-trigger assigned sequence number (however, we really don't know how the trigger populated the value) Theoretically, it may or may not have used a database sequence to assign the number. It would work just the same at the ADFBC level)
3) Refreshing the temporary negative foreign key values in newly-created detail rows for new, composed details of the new composing master row with the definitive primary key value.
So, you should safely be able to change this to a Number, with its Refresh after Insert property set.
(3) Create() on entity implementation was always called once at page load, unexpectedly prepareForDML() always carried on two consequtive rows (either the new row to insert twice or the query's first row retrieved to update and afterwards the new row to insert) having State Management enabled.
If create() is being called only once, then next you should check the value of the "operation" flag that is passed to prepareForDML() to understand if the method is being called for DML_INSERT or DML_UPDATE. Perhaps somehow an existing row is being inadvertently updated so one of the calls to prepareForDML() might be an update? I don't understand how prepareForDML() could fire twice for two new entity objects if the entity object's create() method is only called once. If you have a testcase that illustrates this, please report it to Worldwide Support via Metalink so they can triage and file a bug for you on it.
(4) Swapping selectInputText components with SelectOneChoice, thus avoiding the partial page rendering, I managed prepareForDML() to function logically so that to have only one row to insert, but again since I have validation code in my entity implementation that throws JBO-exceptions, another problem occured. The first time the end-user receives an exception (e.g. invalid Tax Number), the second time he/she corrects it, the created row instance at prepareForDML() doesn't get updated with the new valid Tax Number, but continues to hold the old value at second run. To remind that if insert is successful the navigation moves on to the update page, otherwise it remains at the same (navigation outcome is null).
Are you absolutely sure in this case that a second new row is not getting created?