You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Rick Braddy <rb...@softnas.com> on 2015/09/08 20:54:05 UTC

Session Commits

Hi,

During development of some new processors, I have been looking closely at standard processors to understand best practices. The Developer Guide suggests that one should call session "commit()" upon completion of onTrigger() session processing, which makes sense.  However, I notice in a number of standard processors that commit() is not called at all; e.g., see SplitText processor as an example of this.  Session transfer() gets called but no commit() calls.

So my question is the commit() call necessary, or are sessions being auto-committed if not rolled back?  Is there some penalty to calling session commit() vs. just calling transfer.

Sorry for so many questions, but without a Nifi API reference guide, this seems like the fastest way to understand what's intended by the framework.

Thanks
Rick

RE: Session Commits

Posted by Rick Braddy <rb...@softnas.com>.
Perfect.  That's what I needed to know.

Thanks
Rick

-----Original Message-----
From: Joe Percivall [mailto:joepercivall@yahoo.com.INVALID] 
Sent: Tuesday, September 08, 2015 2:04 PM
To: dev@nifi.apache.org
Subject: Re: Session Commits

Hey Rick,
Calling commit() isn't necessary. The ProcessorSession logic is typically handled by the AbstractProcessor class: if the onTrigger method throws an Exception, the AbstractProcessor will catch the Exception, call session.rollback(), and then re-throw the Exception. Otherwise, the AbstractProcessor will call commit() on the ProcessSession.
It's documented in the developer guide under "Session Rollback". 
Joe- - - - - - Joseph Percivalllinkedin.com/in/Percivalle: joepercivall@yahoo.com
 


     On Tuesday, September 8, 2015 2:54 PM, Rick Braddy <rb...@softnas.com> wrote:
   

 Hi,

During development of some new processors, I have been looking closely at standard processors to understand best practices. The Developer Guide suggests that one should call session "commit()" upon completion of onTrigger() session processing, which makes sense.  However, I notice in a number of standard processors that commit() is not called at all; e.g., see SplitText processor as an example of this.  Session transfer() gets called but no commit() calls.

So my question is the commit() call necessary, or are sessions being auto-committed if not rolled back?  Is there some penalty to calling session commit() vs. just calling transfer.

Sorry for so many questions, but without a Nifi API reference guide, this seems like the fastest way to understand what's intended by the framework.

Thanks
Rick

Re: Session Commits

Posted by Joe Percivall <jo...@yahoo.com.INVALID>.
Hey Rick,
Calling commit() isn't necessary. The ProcessorSession logic is typically handled by the AbstractProcessor class: if the onTrigger method throws an Exception, the AbstractProcessor will catch the Exception, call session.rollback(), and then re-throw the Exception. Otherwise, the AbstractProcessor will call commit() on the ProcessSession.
It's documented in the developer guide under "Session Rollback". 
Joe- - - - - - Joseph Percivalllinkedin.com/in/Percivalle: joepercivall@yahoo.com
 


     On Tuesday, September 8, 2015 2:54 PM, Rick Braddy <rb...@softnas.com> wrote:
   

 Hi,

During development of some new processors, I have been looking closely at standard processors to understand best practices. The Developer Guide suggests that one should call session "commit()" upon completion of onTrigger() session processing, which makes sense.  However, I notice in a number of standard processors that commit() is not called at all; e.g., see SplitText processor as an example of this.  Session transfer() gets called but no commit() calls.

So my question is the commit() call necessary, or are sessions being auto-committed if not rolled back?  Is there some penalty to calling session commit() vs. just calling transfer.

Sorry for so many questions, but without a Nifi API reference guide, this seems like the fastest way to understand what's intended by the framework.

Thanks
Rick

Re: Session Commits

Posted by Bryan Bende <bb...@gmail.com>.
Rick,

I believe it depends on how you implement your processor, meaning what
class you extend from.
If you extend AbstractProcessor, then you can see that it creates a session
and calls commit for you.
If you extend AbstractSessionFactoryProcessor, or implemented the Processor
interface, then you would need to handle creating the session and calling
commit/rollback.

-Bryan

On Tue, Sep 8, 2015 at 2:54 PM, Rick Braddy <rb...@softnas.com> wrote:

> Hi,
>
> During development of some new processors, I have been looking closely at
> standard processors to understand best practices. The Developer Guide
> suggests that one should call session "commit()" upon completion of
> onTrigger() session processing, which makes sense.  However, I notice in a
> number of standard processors that commit() is not called at all; e.g., see
> SplitText processor as an example of this.  Session transfer() gets called
> but no commit() calls.
>
> So my question is the commit() call necessary, or are sessions being
> auto-committed if not rolled back?  Is there some penalty to calling
> session commit() vs. just calling transfer.
>
> Sorry for so many questions, but without a Nifi API reference guide, this
> seems like the fastest way to understand what's intended by the framework.
>
> Thanks
> Rick
>