EDIT

It seems as if the DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() is causing the massive memory usage. In this method new Team instances are created. Replacing this method by a empy implementation which only returns an empty string solves at least the memory issue:

In contrast to the above graph the getCollectorAndFieldNumber() will create a massive load of Teams which can not be garbage collected:

The root cause for the problem is the RegistrationWorkingsetPresenter.onDoneWithTaxonnameEditor() method in which a write enabled transaction is committed at the wrong time. The commit takes place after reloading the registration workingset which causes the whole workingset to be reloaded in the writable transaction since the RegistrationWorkingSetService misses the transaction propagation type being set to Propagation.REQUIRES_NEW in @Transactional(readOnly=true). With REQUIRES_NEW a new read-only transaction would be created even if the service is called in a writable transaction.

Despite having pinned down the root cause to these two findings it is still quite irritating that the DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() can impose such a massive load on the heap even if it is only returning plain strings.

the symptom as described in this issue is no longer reproducible.