Announcement Announcement Module
Collapse
No announcement yet.
JdbcPollingChannelAdapter is calling update query twice for each row selected Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JdbcPollingChannelAdapter is calling update query twice for each row selected

    Via the following code I'm attempting to select and insert a single row at a time but it seems JdbcPollingChannelAdapter is doing two inserts for every select.

    http://pastebin.com/sknNCUCX

    This also produces two identical messages where there should only be one. Any pointers as to why this is happening is appreciated.

  • #2
    This also produces two identical messages where there should only be one.
    Doesn't that suggest that the problem is with the select query? Are you sure it doesn't return more rows than you think? Otherwise what is the evidence that there are two inserts per record?

    Comment


    • #3
      Even if the query selects more than one row shouldn't it only process one row at a time since I have "update-per-row" set to true and "max-rows-per-poll" set to 1? I've verified through debugging that just one row is selected.
      Last edited by digitalsanctum; Aug 25th, 2010, 02:15 PM.

      Comment


      • #4
        Maybe you can help debug the duplicate processing as well then because I don't see it in unit tests?

        Comment


        • #5
          Sure. Could you start by answering my question above? What information do you need? Do any of the unit tests involve doing an insert for the update query? If so, which test(s)?

          Comment


          • #6
            Originally posted by digitalsanctum View Post
            Sure. Could you start by answering my question above?
            Yes, only one row should be processed at a time. You need to be careful with multiple threads if you have multiple endpoints or multiple clients accessing the same table - there is nothing in your code snippet to suggest that this is a problem (but if it was you would only need to add a custom isolation level to the transaction definition in the poller). Is that the question?

            What information do you need?
            Anything that leads to a resolution.

            Do any of the unit tests involve doing an insert for the update query? If so, which test(s)?
            No, but there isn't really any difference between an update and a select from the point of view of the adapter. I just tried it by modifying one of the tests in JdbcPollingAdapterIntegrationTests and it worked as expected. What is your DB platform?

            Comment


            • #7
              Multiple threads are not the issue here. My DB is Oracle.

              Something else I'm finding is that the JdbcPollingChannelAdapter doesn't seem to behave according to the poller subelement. It will poll continuously no matter what value I set for the interval. Here's a simplified version of my original snippet:

              http://pastebin.com/3vDxrJ6L
              Last edited by digitalsanctum; Aug 26th, 2010, 04:02 PM.

              Comment


              • #8
                Originally posted by digitalsanctum View Post
                It will poll continuously no matter what value I set for the interval.
                Sorry, can you explain that a bit? Your new snippet didn't limit the number of rows so you will always suck down all the records every 60s. Is that what you see?

                Comment


                • #9
                  I'm saying the poller has no effect on how often the query is run and in turn how often the messages are produced. Even though I have the poller set to a 1 minute interval, it actually polls continuously with no interval.

                  Comment


                  • #10
                    I'm experiencing this issue: https://jira.springsource.org/browse/INT-751

                    If I set max-messages-per-poll to 1 on the poller element, the continuous polling problem goes away.

                    Comment


                    • #11
                      I found the cause of all my issues. As I already stated in the previous post, I was experiencing INT-751.

                      Although setting max-messages-per-poll to 1 worked around the continuous polling issue, the underlying cause of all of my issues was a circular reference in my Spring configurations.

                      I'm using a mix of context xml files and Java annotations. My xml config has a context:component-scan to pick up my annotated Java class with a @Configuration annotation. The annotated Java class ALSO had a @ImportResource annotation pointing back to the context xml file to pick up properties defined there. This actually caused my jdbc:inbound-channel-adapter defined in the context xml file to run twice with no complaints by Spring!

                      My question is: should Spring have better checking to prevent this sort of thing?

                      Comment


                      • #12
                        Interesting. Spring itself with pure BeanFactory and beans namespace would simply override or replace the second bean definition. My guess is that Spring Integration has auto generated bean ids that never clash by design, so we are overcompensating a little, perhaps. Can you raise a JIRA so someone remember to look at this?
                        Last edited by Dave Syer; Sep 1st, 2010, 03:51 AM. Reason: spelling

                        Comment


                        • #13
                          Done: https://jira.springsource.org/browse/INT-1393

                          Comment

                          Working...
                          X