Experience with use of detachAllOnCommit


Page bloom
 

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:
  1. Avoiding explicit code to carefully perform detachment for objects you're editing in a form or 
  2. Reducing the need to configure and using fetch groups
it can have performance consequences if, say, a web page displays lots of read only data (eg., in a table) and the user only edits one or two objects at a time - eg., in a modal form.

The DN doco on this page http://www.datanucleus.org:15080/products/accessplatform_5_1/jdo/persistence.html 
says:

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.

Join main@datanucleus.groups.io to automatically receive all group messages.