Understanding jbo.doconnectionpooling

Question

We're using adf with jdev 11g. I have two pages, page A and page B. Page A has an Add button, which when clicked will fire this code in it's backing bean to create/insert a new row, which is to be displayed on page B:
OperationBinding createInsertOperationBinding = getBindings().getOperationBinding("CreateInsert");
createInsertOperationBinding.execute();
//Set the status of the new row to STATUS_NEW.
DCIteratorBinding iteratorBinding = getBindings().findIteratorBinding("SecMenuManageApplicationIterator");
PageGroupForManagePageGroupsViewImpl pageGroupVO = (PageGroupForManagePageGroupsViewImpl)iteratorBinding.getViewObject();
PageGroupForManagePageGroupsViewRowImpl pageGroupCurrentRow = (PageGroupForManagePageGroupsViewRowImpl)pageGroupVO.first();
pageGroupCurrentRow.setNewRowState(Row.STATUS_NEW);
This code creates the new row and navigates to Page B, where we see the empty inputs for the new row.
Page B has a Return button, which when clicked, fires code in it's backing bean to check for any pending changes. Basically, we're trying to enforce that if the
user has a pending change on a page, they will be notified via a popup dialog and have the option to save or cancel before leaving. The check for pending changes is done by calling appmodule.isTransactionDirty.
Initially, we had jbo.doconnectionpooling=false and things worked as we wanted. If the user clicked Return on page B without first committing this new record, isTransactionDirty() returned true and the popup dialog gave user the option to save or cancel the changes.
We now have jbo.doconnectionpooling=true to try to minimize the number of db connections. The effect that this has had is that in the above scenario, when a new record is created/inserted in between going from Page A to Page B and the user clicks Return on Page B without committing, isTransactionDirty() now returns false, which means our popup dialog doesn't appear and give the user the option to commit or cancel these changes.
With my limited understanding of setting jbo.doconnectionpooling=true, things are working as they should be expected. I suppose that with this setting, when user clicks Return button on page B and the code which calls isTransactionDirty() is now dealing with a 'different' transaction than the one that was used to create/insert the row, since the jdbc connection is essentially released on each request? So it seems that I can't rely on the isTransactionDirty() to determine if there is a new row that hasn't been committed. How else can I determine this with respect to the fact that jbo.doconnectionpooling=true? Thanks.

Answer 1

Frank, thanks for your help. First of all, thanks for the tip on not using model impl classes in the backing bean. I've since removed that stuff from the backing bean and used the code you suggested to get the current row and set it's state. I found a couple things of interest while messing with this stuff:
1) At one point, I tried to programmatically create/insert the new row in the app module:
public void createInsertPageGroupRow(){
PageGroupForManagePageGroupsViewImpl pageGroupVO = getManagePageGroups();
PageGroupForManagePageGroupsViewRowImpl newPageGroup = (PageGroupForManagePageGroupsViewRowImpl)pageGroupVO.createRow();
newPageGroup.setNewRowState(Row.STATUS_NEW);
pageGroupVO.insertRow(newPageGroup);
Subsequent calls to both the appmodule's isTransactionDirty() and BindingContext.getCurrent().getDefaultDataControl().isTransactionDirty() returned false.
2) In another attempt (the one I ended up using), I executed the declarative Create/Insert method from the pageDef to create the new record. This time, I had the following results:
Calling the appmodule's isTransactionDirty() returned false.
Calling BindingContext.getCurrent().getDefaultDataControl().isTransactionDirty() returned true.
Although I don't understand the difference between calling the appmodule's isTransactionDirty() and the one you suggested, I get the results I expect. Any ideas as to why using the declarative Create/Insert would result in a dirty transaction and creating/inserting programmatically would not? Thanks again.