"Row Cache Spill-Over" oddity when same view bound to a table and button

Question

I have default values for jbo.pers.max.active.nodes=30 and jbo.pers.max.rows.per.node = 70, thus I can avoid spill over if my view has to return less than 70*30=2100 rows. But here is exception from that:
Say for example emp(in scott/tiger schema) table has 1090 records (which is less than 2100 but 1090*2=2180>2100). In my BC4J project it has corresponding emp entity and empView viewobject based solely on the emp entity. I created JClient empty form using wisard where I placed a JTable bound to the empView and a Jbutton with action binding <<commit>> bount to the same empView. The bindings look as following:
jTable1.setModel(JUTableBinding.createAttributeListBinding(panelBinding, jTable1, "EmpView1", null, "EmpView1Iter", new String[] {"Empno", "Ename", "Job", "Mgr", "Hiredate", "Sal", "Comm", "Deptno"}, false, null));
jButton1.setModel(JUButtonBinding.createActionBinding(panelBinding, jButton1, "EmpView1", null, "EmpView1Iter", JUActionBinding.ACTION_COMMIT_TRANSACTION));
When I launch the form, the console shows that the framework does it common tosks to load xmls prepare statements and so on. After a while the framework starts as I think spill-over which continiues and continues with messages like this:
[8761] **update** id=95, parid=-4, collid=0, keyArr.len=1, cont.len=705
[8762] stmt: begin update "PS_ServerModule" set content=empty_blob(), parentid=:1, keycont=empty_blob() where collid=:2 and id=:3 returning content, keycont into :4, :5; end;
[8763] stmt: update "PS_ServerModule" set content=:1, keycont=:2 where collid=:3 and id=:4
[8764] stmt: delete "PS_ServerModule_ky" where collid=:1 and id=:2
[8765] stmt: insert into "PS_ServerModule_ky" values (:1, :2, :3, :4)
[8766] **update** id=96, parid=-4, collid=0, keyArr.len=1, cont.len=705
[8767] stmt: begin update "PS_ServerModule" set content=empty_blob(), parentid=:1, keycont=empty_blob() where collid=:2 and id=:3 returning content, keycont into :4, :5; end;
[8768] stmt: update "PS_ServerModule" set content=:1, keycont=:2 where collid=:3 and id=:4
[8769] stmt: delete "PS_ServerModule_ky" where collid=:1 and id=:2
[8770] stmt: insert into "PS_ServerModule_ky" values (:1, :2, :3, :4)
[8771] **update** id=97, parid=-4, collid=0, keyArr.len=1, cont.len=705
[8772] stmt: begin update "PS_ServerModule" set content=empty_blob(), parentid=:1, keycont=empty_blob() where collid=:2 and id=:3 returning content, keycont into :4, :5; end;
[8773] stmt: update "PS_ServerModule" set content=:1, keycont=:2 where collid=:3 and id=:4
[8774] stmt: delete "PS_ServerModule_ky" where collid=:1 and id=:2
[8775] stmt: insert into "PS_ServerModule_ky" values (:1, :2, :3, :4)
[8776] **update** id=98, parid=-4, collid=0, keyArr.len=1, cont.len=705
[8777] stmt: begin update "PS_ServerModule" set content=empty_blob(), parentid=:1, keycont=empty_blob() where collid=:2 and id=:3 returning content, keycont into :4, :5; end;
[8778] stmt: update "PS_ServerModule" set content=:1, keycont=:2 where collid=:3 and id=:4
[8779] stmt: delete "PS_ServerModule_ky" where collid=:1 and id=:2
[8780] stmt: insert into "PS_ServerModule_ky" values (:1, :2, :3, :4)
But if I remove the action binding from the button the frame launches as should.
As I think the number of records are doubled (as many times as the binding is used in ActionBinding) because I tested it with records count 1000 (less than half of the 70*30) and it worked perfectly.
I use JDeveloper 9.0.3.1 on Windows 2000 Platform.
What is problem? I thought it was prefferible not to get another 'small' view object to use in actionbinding but it turns into spill-over.
And one more question what for the actionbinding needs viewobjectname argument for commit and rollback actions? It commits and rollsback the whole transaction not only the changes in specific viewobject.
Thanks In advance

Answer 1

You're looking at Bug#2772798.
The workaround is in the posting somewhere:
Re: [bc4j] Urgent jbutton binding problem
The JUActionBinding is not only for commiting. You can also do things like ACTION_NEXT and ACTION_PREVIOUS. These actions navigate the RowIterator which happens to be inside a ViewObject. Therefore the name.