Announcement Announcement Module
Collapse
No announcement yet.
One questions on Publisher Transaction Management Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • One questions on Publisher Transaction Management

    Hello Spring Experts,

    I am facing a problem as below:

    We are using in-memory queue and our service method is transactional. Inside the method, we create database record and put the primary key on the async queue and then return. The problem is (event driven) queue listener may kick in early and try to read the database before the service method return (and commit) which will cause "record not found" error.

    Thanks a lot for your help!

    BTW, I read the manual and the obvious supported transactional management is for poller.

  • #2
    Hello.

    How about to use 'persistent queue': http://static.springsource.org/sprin...mplementations and a paragraph about 'QueueChannel Configuration' regarding a note of MessageStore.

    queue listener may kick in early and try to read the database before the service method return (and commit)
    Yes, it is. Some time ago I noticed this obnoxious behavior: https://github.com/artembilan/spring...9c810e66798932
    That's because MessageChannel#send isn't bound to the transaction, it's not a problem of 'poller'...
    From other side should really in-memory queue be bounded to the transaction? It's not his responsibility...
    So, that's my opinion.
    I'll be glad if someone else say other thoughts.

    Take care,
    Artem

    Comment


    • #3
      If you have to use MessageChannel.send() (rather than just returning a value from the service and letting the framework send it for you), and you don't want to use a message store that can participate in the transaction, you might need your service to be wrapped (injected) in another service (so the transaction demarcation is appropriately scoped before sending the message).

      In general, it's best to avoid exposing the messaging infrastructure to your code and use POJOs whenever possible,

      Comment


      • #4
        Originally posted by Gary Russell View Post
        If you have to use MessageChannel.send() (rather than just returning a value from the service and letting the framework send it for you), and you don't want to use a message store that can participate in the transaction, you might need your service to be wrapped (injected) in another service (so the transaction demarcation is appropriately scoped before sending the message).

        In general, it's best to avoid exposing the messaging infrastructure to your code and use POJOs whenever possible,
        Thank you for the answer! wrapped in another service may not work in our case because sending is part of the whole transaction. i.e. if sending the message fails, everything else should roll back.

        It seems to me transactional message store can be the only solution.

        Comment


        • #5
          Originally posted by Cleric View Post
          Hello.

          How about to use 'persistent queue': http://static.springsource.org/sprin...mplementations and a paragraph about 'QueueChannel Configuration' regarding a note of MessageStore.


          Yes, it is. Some time ago I noticed this obnoxious behavior: https://github.com/artembilan/spring...9c810e66798932
          That's because MessageChannel#send isn't bound to the transaction, it's not a problem of 'poller'...
          From other side should really in-memory queue be bounded to the transaction? It's not his responsibility...
          So, that's my opinion.
          I'll be glad if someone else say other thoughts.

          Take care,
          Artem
          HI Artem,

          Thanks! I agree with you that this may not be the responsibility of in-memory queue. We once tried to use the intrusive programmatic transaction management to solve this problem but it is wrong as we require the sending to participate the transaction.

          My option is we have to use transactional message source if we want to elegantly solve the problem. Anyway, in production environment, in-memory queue may be not acceptable at all. The unhappy part for me is to come to this conclusion that async in-memory queue which eases the development at the early stage should not be used at all. We have thought we can easily integrate with external queue e.g. RabbitMQ later with reconfiguration.

          Thanks!

          Comment


          • #6
            I don't know if I'm completely following the use-case, but one approach to wrapping a service activator and other EIP flow components within a transaction is to use a <gateway> whose interface has @Transactional to make that entire flow within the request/reply scope of that gateway participate in the same transaction.

            Comment

            Working...
            X