To avoid memory starvation, each background commands should run in its own session.

The current behaviour (at least, as exploited by the Incode Platform's command service implementation) is:

• a bunch of commands might be queued up to run in the background say 3000 of them
• every 10 seconds, quartz schedules to execute the RunBackgroundCommandsWithReplicationAndReplayJob.
  • nb: this is annotated with @DisallowConcurrentExecution and 
    @PersistJobDataAfterExecution ... so quartz won't run another instance until this one has completed.
• this delegates to BackgroundCommandExecutionFromBackgroundCommandServiceJdo
• this in turn finds the 3000 commands
• in the superclass, BackgroundCommandExecution#doExecute(). these commands are processed one by one, each in their own transaction
• HOWEVER, there is only one session for all of this work, meaning that the size of that session can result in memory starvation (both DataNucleus and Isis hold hashes of all objects that have been modified).

The fix is to create a new session for each command, rather than just a single session.