Announcement Announcement Module
No announcement yet.
Lighter Pointcuts? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lighter Pointcuts?

    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:advisor pointcut="execution(public * ing(..))" advice-ref="txRequired"/>
    <aop:advisor pointcut="execution(public * ..))" advice-ref="txRequired"/>
    <aop:advisor pointcut="execution(public * ing(..))" advice-ref="txRequired"/>
    <aop:advisor pointcut="execution(public * ..))" advice-ref="txRequired"/>



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

    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
    Last edited by Isaac Rodriguez; May 17th, 2010, 08:08 AM.

  • #2
    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:advisor pointcut="execution(public * 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


    • #3
      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)


      • #4
        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.