Announcement Announcement Module
Collapse
No announcement yet.
Poller and transaction Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Poller and transaction

    Hi all,

    In spring Integration, when using a Poller with a transaction manager, in can see in log that the poller opens, commits and closes a transaction at every poll, even if there is no message. In my case, the interval-trigger is set to 1s.

    So I've a transaction used every second. Is there a way to have a transaction use only if there is a message?

    Regards,

    David

  • #2
    The transaction begins before the poll so that the poll itself would be included in the transaction. That is mostly useful when you are using an inbound-channel-adapter to invoke a method that you want to include in the transaction boundary. There are a couple things that you can do to avoid that. First, if it works for your use-case, you can simply add transaction support on the methods that are being invoked within endpoints (e.g. @Transactional on a method that is referenced by a "service-activator"). Second, you can decrease the cost of the transaction by using something like Spring's LazyConnectionDataSourceProxy: http://static.springsource.org/sprin...urceProxy.html

    Does the first option work for your use-case? If not, can you provide some more information? We might consider other transaction boundary options for Spring Integration 2.0.

    Thanks,
    Mark

    Comment


    • #3
      If the source would be peekable the poller could peek first and then open a transaction if it likely needs to read something. This might be worth a JIRA.

      Comment


      • #4
        Mark,

        yes it works with adding the transactional annotation to the methods called by spring-integration.

        But in a general point of view, if you use a transaction poller, it creates lot of transaction for doing nothing. It could be interesting to postpone the transaction boundary when a message is received.

        Regards,

        David

        Comment


        • #5
          David,

          Could you open an issue in JIRA for this? We can explore the options even if the issue ends up being superseded by another one. The main problem I see is that the only purpose for transactional demarcation at the poller level is when the actual receive() call needs to be part of the transaction.

          Therefore, I see 2 options for this:
          1) support transactions after the receive - in most cases using a dispatching-channel (one without a 'queue') with a transaction interceptor should be the right boundary
          2) support some kind of peek() prior to receive() if possible... the problem is that provides a window of vulnerability

          I have a feeling that option 1 is sufficient for your case because the receive call is not relevant for a transaction anyways? (it could be if using an inbound-channel-adapter or in the future if we have "transactional" channels).

          Comment


          • #6
            Hi,

            I've created a Jira ticket: http://jira.springsource.org/browse/INT-744

            Regards,

            David

            Comment

            Working...
            X