Spring AMQP/RabbitMQ i Hibernate Transaction Mananger

Question

Mam aplikację Spring, która używa Hibernate i PostgreSQL. Używa również Spring AMQP (RabbitMQ).

Używam menedżera Hibernate transakcja skonfigurowany w następujący sposób:

<bean id="transactionManager" 
    class="org.springframework.orm.hibernate3.HibernateTransactionManager" 
    p:sessionFactory-ref="sessionFactory" p:dataSource-ref="dataSource" /> 

Używam SimpleMessageListenerContainer asynchronicznego odbioru komunikatu skonfigurowany jako:

@Resource(name="transactionManager") 
private PlatformTransactionManager txManager; 

@Autowired 
private MyListener messageListener; 

@Bean 
public SimpleMessageListenerContainer mySMLC() 
{ 
    final SimpleMessageListenerContainer container = new SimpleMessageListenerContainer(); 
    container.setConnectionFactory(rabbitConnectionFactory); 
    container.setQueueNames("myQueue"); 

    final MessageListenerAdapter adapter = new MessageListenerAdapter(messageListener); 
    adapter.setMessageConverter(converter); 
    container.setMessageListener(adapter); 
    container.setChannelTransacted(true); 
    container.setTransactionManager(txManager); 
    return container; 
} 

Więc w zasadzie mam określonej że recepcji wiadomości muszą być transakcyjne. Moduł nasłuchujący wywołuje usługę, która może mieć metody oznaczone przez @Transactional i prawdopodobnie wykonywać operacje CRUD na DB.

Moje pytanie brzmi, czy istnieje problem z korzystaniem z HibernateTransactionManager do zarządzania transakcją na poziomie SimpleMessageListenerContainer? Czy wystąpią jakiekolwiek problemy z użyciem menedżera transakcji DB do zawijania otrzymywania wiadomości od RabbitMQ?

Nie oczekuję tutaj XA. Chcę tylko upewnić się, że jeśli jakiekolwiek operacje na DB przez usługę nie powiedzie się, wiadomość nie zostanie potwierdzona do brokera RabbitMQ.

Answer 1

Zgodnie ze źródłami Spring głównym celem właściwości transactionManager MessageListenerContainer jest rozpoczęcie transakcji na wiadomości odebranej przed wywołaniem przez odbiornik oraz zatwierdzenie lub wycofanie transakcji po powrocie odtwarzacza lub zgłoszeniu wyjątku. Nie ma więc potrzeby tworzenia metod detektora @Transactional, ponieważ transakcja będzie już uruchomiona przed wywołaniem metody detektora.

W przypadku błędu w detektorze zostanie zgłoszony wyjątek, transakcja DB zostanie wycofana, a komunikat nie zostanie wysłany do brokera komunikatów (wycofanie transakcji jms). Ale bez XA mogą istnieć duplikaty wiadomości. Na przykład po pomyślnym zatwierdzeniu transakcji DB nie można wysłać połączenia do brokera wiadomości i potwierdzenia w brokerze. Po ponownym połączeniu broker może dostarczyć zduplikowaną wiadomość. Jeśli się przyznasz, nie musisz zajmować się XA.