Memory spiking when ExecutionContextImpl#retrieveObjects encounter database connections lost

[LennonChin]

I'd like to ask if there's a specific reason for storing all exceptions in ExecutionContextImpl#retrieveObjects with failures.add(e); in following for loop codes.

@Override
public void retrieveObjects(boolean useFetchPlan, Object... pcs)
{
    if (pcs == null || pcs.length == 0)
    {
        return;
    }

    // TODO Consider doing these in bulk where possible if several objects of the same type
    List<Throwable> failures = null;
    for (Object pc : pcs)
    {
        if (pc == null)
        {
            continue;
        }

        try
        {
            clr.setPrimary(pc.getClass().getClassLoader());
            assertClassPersistable(pc.getClass());
            assertNotDetached(pc);

            DNStateManager sm = findStateManager(pc);
            if (sm == null)
            {
                throw new NucleusUserException(Localiser.msg("010048", StringUtils.toJVMIDString(pc), getApiAdapter().getIdForObject(pc), "retrieve"));
            }
            sm.retrieve(useFetchPlan);
        }
        catch (RuntimeException e)
        {
            if (failures == null)
            {
                failures = new ArrayList<>();
            }
            failures.add(e);
        }
        finally
        {
            clr.unsetPrimary();
        }
    }

    if (failures != null && !failures.isEmpty())
    {
        throw new NucleusUserException(Localiser.msg("010037"), failures.toArray(new Exception[failures.size()]));
    }
}

In our use case, the volume of business requests is extremely high. When the database suddenly crashes and all database connections are lost, all operations accessing the ResultSet will throw a large number of exceptions, storing them all in a List would cause JVM memory to spike.

[andyjefferson]

JDO spec, JDOException thrown could have multiple runtime exceptions.

You could contribute a feature controlled by a persistence property, something like "datanucleus.saveNestedExceptions" (or better name - values true|false) and if false then skip the storing of failures (but would still need to throw an exception if there are any failures). Same would apply to other PM methods.