Lighter Pointcuts?

[Isaac Rodriguez]

I’ve defined in my applicationContext.xml many beans and I want to declare transactions just for some of them. I’ve defined a pointcut for each method that I want to be transactional:

<aop:config>
<aop:advisor pointcut="execution(public * com.company.project.services.Demo1Service.doSometh ing(..))" advice-ref="txRequired"/>
<aop:advisor pointcut="execution(public * com.company.project.services.Demo1Service.execute( ..))" advice-ref="txRequired"/>
<aop:advisor pointcut="execution(public * com.company.project.services.Demo2Service.doSometh ing(..))" advice-ref="txRequired"/>
<aop:advisor pointcut="execution(public * com.company.project.services.Demo2Service.execute( ..))" advice-ref="txRequired"/>

etc...

</aop:config>

<tx:advice id="txRequired" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="*"/>
</tx:attributes>
</tx:advice>


Helped by a profiler, I have discovered that the consumption of the memory is too high (over 1MB for each pointcut). Due to this, the total amount of the memory is oversized.
The use of a pointcut penalize so much? Is there another way to define lighter pointcuts?

Thanks in advance

[Isaac Rodriguez]

Hi there,
I've been doing some research and found that when defining pointcuts in the applicationContext.xml, proxies are generated which contain two advisors: ExposeInvocationInterceptor & DefaultBeanFactoryPointcutAdvisor.
DefaultBeanFactoryPointcutAdvisor ones contain an AspectJExpressionPointcut type pointcut that have a property called shadowMapCache.
As I’ve many beans defined in my applicationContext.xml this Map stores lots of entries: in the test I've done every Map has more than 3000 entries for each pointcut and this is what eventually causes the high memory consumption (over 100MB)
As I explained in my first post I’ve defined many beans in my applicationContext.xml and I’ve defined method-level pointcuts like:

<aop:config>
<aop:advisor pointcut="execution(public * com.company.project.services.Demo1Service.doSometh ing(..))" advice-ref="txRequired"/>

I have also been testing by defining class-level pointcuts and although it has reduced the memory consumption significantly, it is still too high (over 80MB).
Finally, to define a smaller number of advisors, I’ve defined packet-level pointcuts.
The memory consume is lower but there are generated many unnecessary proxies.
I’ve done the same test by defining transactions using annotations and memory consume has dropped down. In this case, the generated advisor is a TransactionAttributeSourceAdvisor one and the pointcut is a TransactionAttributeSourcePointcut one. Apparently just an advisor is generated for the entire application.
Am I right with my thoughts? Defining pointcuts in a declarative way penalizes and should be avoided when it is possible? or is there another way to avoid this?
Which are the "best practices" on this topic?
Best regards

[iocanel]

Here are some thoughts

• You can use compile time weaving.
• You can try tune it by switching between dynamic proxies and cglib proxies
• Try VM options such as -Xmn that might affect (not sure but might)

[Isaac Rodriguez]

Thanks a lot for your answer iocanel,

• You can use compile time weaving.

I’ve tried this solution, but in spite of reduced memory consumption, we can’t use it because I think that this solution requires the use of JDK 1.5 and we are currently working with the 1.4 one. This is the reason why we define the aspects and transactions on XML (in previous posts I have written some examples). Is it possible to reduce the memory consumption defining aspects and transactions using XML?

• You can try tune it by switching between dynamic proxies and cglib proxies.

I've already tried this but in the end the advisor used by the two proxies is the same (DefaultBeanFactoryPointcutAdvisor) so the memory consumption is very high.

• Try VM options such as -Xmn that might affect (not sure but might).

If I'm right this parameter is able to increase the heap size so it is more difficult to occur an OutOfMemoryError. However this will not make the memory consumed by the application go down.