Russell, There are a couple of use cases I can think of where you'd want AbstractSessionFactoryProcessor over AbstractProcessor:
1) You only want to update the State Manager after a successful commit has taken place. Because AbstractProcessor.onTrigger() calls commit for you, you can't add code after that to update the state map. 2) I am working on a processor that needs to keep the same session across multiple calls to onTrigger, basically its a transactional thing and I don't know when it will end. If something bad happens in the meantime, I need to roll back that original session. 3) What Mark said :) Regards, Matt On Fri, Mar 17, 2017 at 12:45 PM, Russell Bateman <[email protected]> wrote: > The ability to create a new session is conferred by extending > AbstractSessionFactoryProcessor(in lieu of AbstractProcessorwhich further > restricts Processor, among other things, removing the session factory) > giving one the option of calling sessionFactory.createSession(). This begs > the question of why or when would I wish to create a new session rather than > operate within the one I'm given (by AbstractProcessor)? >
