clustered poller solutions best practices

[rgupta12]

We have inbound pollers

 <int-jdbc:inbound-channel-adapter

running on two weblogic servers hitting a single database, I know it is has been discussed (table locking, etc), but is it suggested to have a single poller (with a fail over mechanism), we are running into concurrency issues, and now locking the entire table (isolation level is serializable), which seems to lock entire table. Without this, both pollers are picking up same records

      <int:transactional transaction-manager="transactionManager" propagation="REQUIRED" isolation="SERIALIZABLE"

[Dave Syer]

I think the bottom line is that JDBC polling is not a very efficient messaging solution. However, your mileage my vary, and the performance of high isolation levels depends a lot on the RDBMS server (platform and configuration). If you need to prevent duplicate messages you need that high isolation.

However, if you are getting deadlock loser exceptions in your pollers it might be OK just to ignore them - all it means is that you won't be scaling the poller as well as it might, but if the downstream processing is intensive it probably doesn't matter if you skip a poll here and there.

I tested with Oracle (default XE out of the box) and got pretty good results with multiple pollers (it scaled), but I know other RDBMS are completely awful at concurrent access. Some don't even work at all - which is why we added an AOP interceptor to Spring Integration to help with concurrent pollers in the same JVM (I found that H2 and Derby both required that, but Oracle and MySQL were fine).