Oracle SOA Database Adapters provide a polling mechanism that will periodically query a table to see if a there is a new or changed record. If so, it can trigger a BPEL process. This is enormously useful. However, on one client I ran into a series of issues with database pollers in a clustered environment when they … collided. (queue dramatic music)
The issue began one quiet morning early in the project after I started my WebLogic Admin Server and 2 SOA 11g Managed Servers. I then deployed my process with my shiny new database poller. I was very excited to see it work in the Development Environment. I had tested it the night before in my local VM and it worked great.
I won’t bore you with the details of what the overall process did, but suffice it to say, I was not excited with the database error I received when the pollers fired. You heard me right … pollers.
I did NOT anticipate that SOA would have a separate database poller for each managed server for the same process. However, after consulting with colleagues, I found that they too had seen this rather odd and seemingly illogical behavior.
Luckily after a bit of sleuthing, I found a nice solution – the Distributed Polling flag. As usual, the A Team came to the rescue with an outstanding article that nicely explained the inner guts of how this works: DB Adapter – Distributed Polling (SKIP LOCKED) Demystified.
In short, this flag doesn’t allow more than 1 server to issue a lock on a table at a given time. In effect, this ensures that you end up with 1 database poller for your process and not 1 per managed server (however, there is a twist to this that I’ll discuss in a moment). Read the complete article here.
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.