[jboss-jira] [JBoss JIRA] (WFLY-3936) Unnecessary transactions for non-existent lifecycle event callbacks.

[Sławomir Wojtasiak (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sławomir Wojtasiak updated WFLY-3936:
-------------------------------------
    Description: 
I have found an issue in the semantic of the stateless and stateful session beans initialization policy. Every time a component is configured regardless of the existence of the lifecycle event callbacks, lifecycle interceptors responsible for transactions management are registered and they create new transactions suspending the current ones every time components are created and destroyed. Wildfly does not use the component pool for stateless session beans by default, so whenever we call a method on a stateless component which does not have any lifecycle callback handlers two unneccessary transactions (REQUIRES_NEW semantic) are created. The first one is created when the component is initialized and the second one when the component is destroyed. In other words, even if there is no @PostConstruct/@PreDestroy callback new transactions are created just to support them.

The PostConstruct/PreDestroy lifecycle callback interceptor methods for a stateless session bean execute in an unspecified transaction context, so purely theoretical these interceptors could even be completely ignored what would yield in significant performance improvements over the stateless session beans invocations. Anyway using the transaction interceptors in conjunction with the lifecycle event handlers for stateless session beans is probably intended, so I have prepared a fix which just ignores these interceptors as long as there are no lifecycle event handlers for a given component. I have tested the fix with @PostConstruct, @PreDestroy and SessionBean interface related lifecycle event callbacks.

Provided pull request fixes the same problem for stateful session beans too.

In addition I also found a minor inconsistency in the way components are configured. There is a flag "description.isIgnoreLifecycleInterceptors()" used in order to ignore lifecycle interceptors when needed. It is consequently used in the default components initialization procedure, but specialized configurators for stateful and stateless session beans silently ignore it. I have also added a fix for that.

I have prepare a simple performance report by executing one stateless method with TransactionAttribute.NEVER, about 1000000 times in a loop:
Before the fix:
Three calls in a row: 33 sec, 31 sec, 31 sec.
After the fix: 
Three calls in a row: 24 sec, 22 sec, 22 sec.

It is not a common use case for stateless beans, but it shows that the call is about 41% slower before the fix.


  was:
I have found an issue in the semantic of the stateless and stateful session beans initialization policy. Every time a component is configured regardless of the existence of the lifecycle event callbacks, lifecycle interceptors responsible for transactions management are registered and they create new transactions suspending the current ones every time components are created and destroyed. Wildfly do not use the component pool for stateless session beans by default, so whenever we call a method on a stateless component which does not have any lifecycle callback handlers two unneccessary transactions (REQUIRES_NEW semantic) are created. The first one is created when the component is initialized and the second one when the component is destroyed. In other words, even if there is no @PostConstruct/@PreDestroy callback new transactions are created just to support them.

The PostConstruct/PreDestroy lifecycle callback interceptor methods for a stateless session bean execute in an unspecified transaction context, so purely theoretical these interceptors could even be completely ignored what would yield in significant performance improvements over the stateless session beans invocations. Anyway using the transaction interceptors in conjunction with the lifecycle event handlers for stateless session beans is probably intended, so I have prepared a fix which just ignores these interceptors as long as there are no lifecycle event handlers for a given component. I have tested the fix with @PostConstruct, @PreDestroy and SessionBean interface related lifecycle event callbacks.

Provided pull request fixes the same problem for stateful session beans too.

In addition I also found a minor inconsistency in the way components are configured. There is a flag "description.isIgnoreLifecycleInterceptors()" used in order to ignore lifecycle interceptors when needed. It is consequently used in the default components initialization procedure, but specialized configurators for stateful and stateless session beans silently ignore it. I have also added a fix for that.

I have prepare a simple performance report by executing one stateless method with TransactionAttribute.NEVER, about 1000000 times in a loop:
Before the fix:
Three calls in a row: 33 sec, 31 sec, 31 sec.
After the fix: 
Three calls in a row: 24 sec, 22 sec, 22 sec.

It is not a common use case for stateless beans, but it shows that the call is about 41% slower before the fix.




> Unnecessary transactions for non-existent lifecycle event callbacks.
> --------------------------------------------------------------------
>
>                 Key: WFLY-3936
>                 URL: https://issues.jboss.org/browse/WFLY-3936
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.1.0.Final, 8.2.0.CR1
>         Environment: WildFly 8.2.0.CR1 + OracleJDK7 + Gentoo Linux
>            Reporter: Sławomir Wojtasiak
>            Assignee: David Lloyd
>
> I have found an issue in the semantic of the stateless and stateful session beans initialization policy. Every time a component is configured regardless of the existence of the lifecycle event callbacks, lifecycle interceptors responsible for transactions management are registered and they create new transactions suspending the current ones every time components are created and destroyed. Wildfly does not use the component pool for stateless session beans by default, so whenever we call a method on a stateless component which does not have any lifecycle callback handlers two unneccessary transactions (REQUIRES_NEW semantic) are created. The first one is created when the component is initialized and the second one when the component is destroyed. In other words, even if there is no @PostConstruct/@PreDestroy callback new transactions are created just to support them.
> The PostConstruct/PreDestroy lifecycle callback interceptor methods for a stateless session bean execute in an unspecified transaction context, so purely theoretical these interceptors could even be completely ignored what would yield in significant performance improvements over the stateless session beans invocations. Anyway using the transaction interceptors in conjunction with the lifecycle event handlers for stateless session beans is probably intended, so I have prepared a fix which just ignores these interceptors as long as there are no lifecycle event handlers for a given component. I have tested the fix with @PostConstruct, @PreDestroy and SessionBean interface related lifecycle event callbacks.
> Provided pull request fixes the same problem for stateful session beans too.
> In addition I also found a minor inconsistency in the way components are configured. There is a flag "description.isIgnoreLifecycleInterceptors()" used in order to ignore lifecycle interceptors when needed. It is consequently used in the default components initialization procedure, but specialized configurators for stateful and stateless session beans silently ignore it. I have also added a fix for that.
> I have prepare a simple performance report by executing one stateless method with TransactionAttribute.NEVER, about 1000000 times in a loop:
> Before the fix:
> Three calls in a row: 33 sec, 31 sec, 31 sec.
> After the fix: 
> Three calls in a row: 24 sec, 22 sec, 22 sec.
> It is not a common use case for stateless beans, but it shows that the call is about 41% slower before the fix.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)