Clustered IS and JDBC adapter notifications

Hi. I noticed at Advantage that adapter notification is not supported if using JDBC adapters and clustered Integration Servers.

Here’s the blurb at:

Integration Server clusters do not support JDBC Adapter notifications because the Integration Server publish mechanism cannot enable client side queuing in a clustered environment. (Client side queuing is used for duplicate message detection.) Therefore JDBC Adapters running on a clustered Integration Server would not have any means for providing detection of duplicate messages for notifications.

Has anyone dealt with this yet? Is the work around to install a separate (non clustered) IS runtime and create JDBC adapter instances requiring adapter notifications here ?



I’m working on a project right now that uses JDBC adapter notifications in a clustered environment under 6.0.1 SP2. Our administrator group asked webMethods about this. We were told that as long as your notification publishes to a Broker (i.e. not using local IS publish) then you are OK. You may see some duplicate publish messages in the server log, but you can ignore those.

I’ve seen this work in some simple test cases, but we have not yet put it into a high-stress production environment.

Skip, thanks for this information.

So the “duplicate publish messages” aren’t real duplicates ?


I think that it is possible to have once-and-only-once delivery with JDBC adapter in the cluster when the adapter is publishing to the Broker. The Broker will drop the duplicate document (it tracks the pubSequence number for each client). The ISes in the cluster publish through the same Broker client (DefaultClient) and they could store in the repository the last pubSequence number. When one IS crashes the other can pick up the work and resubmit the document to the Broker. If the pubSeqn is the same the Broker will drop it.
I think this is the way the once-and-only-once could work in a cluster. I don’t know if this is really how it has been implemented but this is similar to how the once-and-only-once worked in the old ES-style adapters (I coded one adapter that supported this feature myself).

However there is also the issue of preserving document order and I think this is why webMethods does not support JDBC notifications in the cluster. It is very easy to imagine a scenario where the order of the notifications is not preserved. For example if first IS in the cluster picks up a notification but the IS is overloaded and processes the notification slowly while there happens another notification which gets picked up by the other IS in the cluster. If the other IS is real fast the second notification may be published first to the broker. I think this scenario is what webMethods describes in the JDBS 6.1 adapter user guide.

I think that a workaround for notifications not being supported in a cluster is to create an extra package and within the package have the JDBC adapter connection and adapter notification services. Then you would deploy this “notification” package only on one IS in the cluster. This way the ISes in the cluster would not be identical in terms of packages. I think that this is still better then creating and extra out-of-cluster IS for running the notifications only.

Wayne I read your posting here I think its not really correct. First I do not see relationship with JDBC adapter notifications and publishing to Broker? JDBC Adapter polling notification does publish a document to IS as result of DB operation and getting result set back from databse! And ofcourse you can publish a document to Broker as well but Notification itself does not do that!

As far as I recal the porblem with Notifications in a cluster is related to Adapter runtime WmART package rather than JDBC Adapter. Although its only JDBC adapter using some uniques features of WmART to cause the porblem other adapters I was told are not afected by it. But do not quote me on that one
Basic issue as I understand it is in Cluster JDBC does polling notifications and both IS query DB but before that occures JDBC Adapter must get some type of object lock in Cluster repoitory and that is not working as repo failes! SO as result you will get errors nad duplicate notifcationa and duplicate dicuments error in IS. This case JDBC cannot support only once notification feature. That is a problem to my knowledge and so far no fixes or SPs have corrected that one! Also I did not see anything about this in release notes of New 6.1 iether.
The issues described by Fenek may be a porblem as well although I did not ruin into that one. The solutions discussed earlier I think cabn void this issue by basically taking out JDBC notifications out of the cluster formation.


As far as I understand, using JDBCAdapter for the notification does present the problem described by Igor. The real fix for this issue will come out for the next major release. In order to mitigate the problem with the notification, I usually recommend for the OS-level clustering for the IS(host the jdbc adapter) and wm-clustering for others. Until the final solutions comes out from wm.


I am wondering if OS-level clustering is supported in IS.

Let me know if it has been implemented anywhere, we need it badly.

Not for JDBC but for WmJBoss package which is hosting the JMS queues that external application is talking to, and JMS clustering is not supported in JBossMQ.

Thanks in advance.


I have implemented windows clustering/ veritas /sun clustering for the
IS. All seem work fine. You have to customerize or build your own scripts to do those though. I am not famliar with JBoss package. Since Broker supports JMS queue, i would think that’s a better way to host the queue. I am not sure how the JMS queue implemented in JBoss, you may do some creative way to figure them out. If the JMS queue is file based, you may have it on a shared mount point.



We settled on JBoss as the external application needed JNDI to access JMS queues and broker JMS does not have one.

Anyways, for OS level clustering of IS on Sun cluster: Do you mind sharing the scripts?



Sorry for asking to share YOUR scripts.

However, would it be OK if you could give some pointers to create the same for ourselves?

I mean, what (and how) exactly you monitor in IS to identify that it is no more live and hence to switch over to start other instance?


Please also note that if you do use JDBC notifications on a cluster by enabling the notification on one server and not on the other, you should ONLY use basic notifications.

Any others will mean you lose the data in the table when enabling the JDBC Notifications on the system that had the notification disabled… :slight_smile:

Can anyone tell me how to use WmTomCat package?? none of the services presented in the package has any input/output variables!!!
or is there any URL for the API used in WMTomcat services or is there any documentation?
anyone of you kindly help me!

I suppose webMethods has a fix for this.

Fix Name: “webMethods Integration Server 6.1 Fix 6”

This fix addresses the following issue:

Polling notifications are not cluster aware.

When a polling notification is distributed across a cluster, the
individual notifications’ schedules are not coordinated. This
problem leads to document duplication and ordering problems. This
fix allows enabled instances of the same polling notification,
deployed in a cluster, to coordinate their executions, providing
better fail-over and load distribution support for the cluster.

hi friends,
i have insert/delete/update notifications on a table with 3 fields.there are three flow services and three triggers which takes the insert/upadte/delete notification publishable docs and publish three docs respectively with an additional parameter record status set to U, I, D for updates, inserts and deletes. so the publihsbale doc has 4 fields, now i need this published document to carry out further processing,.
how wil i implement this using basic notification.
1)what will the structure of database table which i create?
2) Can some one help me to write the trigger for inserts, updates or deletes on the table?
thanks and regards