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:

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?