Skip,
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.
Wayne,
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.
#Integration-Server-and-ESB#Adapters-and-E-Standards#webMethods