question about transaction interceptor

[Darren Shepherd <da...@gmail.com>]

The current impl of the transaction interceptor is that its placed on 
all public/protected methods of anything that extends GenericDaoBase. 
This means that a simple findX() call ends up going through that 
interceptor about 4 or more times as it goes through other methods likes 
searchIncludingRemoved, searchIncludingRemoved, createPartialSelectSql, etc.

Has it always been this way?  Or did the transition to spring introduce 
this.  The DB transaction interceptor code gets hit a lot.  I mean A 
LOT!  Good thing we have a JIT.

Darren

Re: question about transaction interceptor

[Kelven Yang <ke...@citrix.com>]

On 9/4/13 9:36 AM, "Darren Shepherd" <da...@gmail.com> wrote:

>The current impl of the transaction interceptor is that its placed on
>all public/protected methods of anything that extends GenericDaoBase.
>This means that a simple findX() call ends up going through that
>interceptor about 4 or more times as it goes through other methods likes
>searchIncludingRemoved, searchIncludingRemoved, createPartialSelectSql,
>etc.
>
>Has it always been this way?  Or did the transition to spring introduce
>this.  The DB transaction interceptor code gets hit a lot.  I mean A
>LOT!  Good thing we have a JIT.

It has been there before Spring, however, Spring change make it more
costly, since the filtering is not as intelligent as it would be (like to
check txn attribute in @DB which we had before).

Removing @DB would make more sense if we consider of performance
implications of it.

Kelven

>
>Darren