Note: groups.io will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
Experience with use of detachAllOnCommit
To all my fellow DNers out there you might find this useful:
I was experimenting with detachAllOnCommit and noticed that while it can be convenient by:
The DN doco on this page http://www.datanucleus.org:15080/products/accessplatform_5_1/jdo/persistence.html
The bottom line is to not use detachment if instances will only be used to read values.The importance of this line should not be underestimated.
Detachment is not a zero cost feature so use it sparingly and this applies to individual calls to detachCopy or 'detachment of the entire L1 cache on commit' which is what happens when 'detachAllOnCommit' is set to true.
We did an experiment measuring the rendering time of a page that had a table with 9 top level objects displayed. Each of these had approximately 4 other associated objects required to render the data required for each entry in the table - so roughly a total of 36 objects.
This tables shows the average render time of the page for the different values of detachAllOnCommit:
DetachAllOnCommit | Average Render time
false | 744 ms
true | 1083 ms i.e. 45% slower!!!!
So explicitly detaching only those objects that need to be detached would seem to be the best solution for optimal performance rather than setting DetachAllOnCommit=true which forces *every* object in the L1 cache to be detached.
While it definitely requires a little more work to explicitly detach object that can be modified in other parts of your app (eg., in a form) we believe that the performance advantage outweighs the burden of the extra coding effort.
The interesting thing is that, from my understanding, native "JPA Mode" is the like having DetachAllOnCommit=true - does that mean JPA mode is naturally not optimal in terms of performance as it always forces a detach of all L1 objects at each commit?