A case of oracle.jbo.TooManyObjectsException : Change createRowFromResultSet to createInstanceFromResultSet

Printer-friendly versionPDF version

So there are some documented cases of this exception happening and some remedies there-in, if you google this problem.

What if you think you don't fall into this category. So let me "describe" for you a scenario and if you fall into this category, this might save you some pain in troubleshooting this scenario. Again, this might not be the case for you and simple plain vanilla advice might be all you need. If the description some how matches your use case, you can try the solution I propose.

So we have a custom VO, entity based, but based on a certain id column we augment the data in the row via external WS calls. We do this via populateAttribute(int index, Object value, boolean sendNotification, boolean markAsChanged, boolean saveOriginal) call. If we are augmenting the row data on a persistent attribute, we call it with markAsChanged true and if its a transient field than this flag is set false. This was initially done in the VOImpl overridden method "createRowFromResultSet" after the call to super(). After the call to super return a VORowImp class, I would take the entity row out and call a method on the entity level to augment the entity row with WS data. Lets call this mechanism, the hook that would augment the EntityImpl row with the date from WS. This was done via the populateAttribute api call I mentioned earlier. We did it at entity level to avoid calling the WS needlessly if the row was already loaded for a session (this you can control with a flag at the entity level with a transient attribute).

It was fine for a while untill we started noting the TooManyObjectsException. What happened was that we had another VO that needed to reuse the entity which was augmented with the WS data. We again overrode the "createRowFromResultSet" method in the new VO to call the entity level hook method to augment the data. Now when the first VO has already loaded the data, and the crucial point being that the WS call had brought in some changes to data persisted previously. This would mark that entity row in a dirty state becuase of the update. Now when the second VO would also create a row and based its VO-Row on that changed EO-Row, we were hitting the dreaded oracle.jbo.TooManyObjectsException.

By chance I changed the "createRowFromResultSet" method to "createInstanceFromResultSet" in the VOImpl class. And *BAM* the long standing headache was gone. I had even a junit test case that would consistently reproduce the issue. The change apparently solved the issue. While I have debugged ADF code a lot, I did not feel like doing so in this case, with the solution in hand. Whats the difference maybe some ADF developer can shed light on that. Meanwhile if what I describe is your usecase and your being bitten by this anoyance. This change helped me out.

I am using ADF 11g version currently as a Fusion developer.


Top level category:

Add new comment