Announcement Announcement Module
Collapse
No announcement yet.
DBMS_AQJMS.ALTER_SUBSCRIBER() calls on durableTopic Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • DBMS_AQJMS.ALTER_SUBSCRIBER() calls on durableTopic

    Hello,

    I have a somehow working configuration of listener-containers, listeners and subscriptions on durableTopics with Spring 2.5.5.A and an Oracle 10g. Everything is working fine, except for a huge amount of calls (and of cpu time) of DBMS_AQJMS.ALTER_SUBSCRIBER() and ADD_SUBSCRIBER() on the database.

    The configuration of the listener-containers is as follows

    <jms:listener-container client-id="myClientIDOne" destination-type="durableTopic" connection-factory="connectionFactory" message-converter="myMessageConverter" concurrency="1-2" transaction-manager="jmsTransactionManager">
    <jms:listener subscription="subscribernameOne" destination="topicOne" ref="myServiceOne" method="serviceMethodOne"/>
    </jms:listener-container>

    <jms:listener-container client-id="myClientIDTwo" destination-type="durableTopic" connection-factory="connectionFactory" message-converter="myMessageConverter" concurrency="1-2" transaction-manager="jmsTransactionManager">
    <jms:listener subscription="subscribernameTwo" destination="topicOne" ref="myServiceTwo" method="serviceMethodTwo"/>
    </jms:listener-container>

    I also tried using the same client-id for each listener-container but to no avail. Has this something to do with J2EE compliance mode? Any other suggestion maybe?

    Thanks,
    Henning

  • #2
    Solution found

    For those with a similar problem, here's the solution to that problem.

    I tried setting cache="consumer" for the listener-container, because as it turned out, the session and the consumer were closed and created again for each fetch, which caused the alter_subscriber and add_subscriber calls. Caching alone didn't help, as the session was reused in theory, but the transaction created a new one every time. What finally helped, was combining the caching with a DataSourceTransactionManager instead of the JmsTransactionManager, which I used before.

    Code:
    <bean id="jmsTransactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    	<property name="dataSource" ref="dataSourceJMS" />
    </bean>
    
    <jms:listener-container cache="consumer" client-id="${jms.clientid}" destination-type="durableTopic" connection-factory="connectionFactory"  message-converter="myMessageConverter" concurrency="1-2" transaction-manager="jmsTransactionManager" >
    	<jms:listener subscription="subscriptionOne" destination="topicOne" ref="myService" method="myMethod" />
    </jms:listener-container>
    Instead of using the DataSourceTransactionManager, I guess one could use acknowledge="transacted" for a locally transacted Session.

    Comment

    Working...
    X