Actually the network overhead of pooling is minimal since the JDBC adapter is only invoking an SQL statment or a stored procedure and the actual work is done at the engine side. (the SQL statment has the compiling overhead)… if there is no results then no overhead to consider.
The notification approach is better to maintain the applications loose from each other an in a worst case scenario (if the pooling interval is 15 seconds the default) is having a certain table entry wait for about 14+ seconds!!! The average is much less if you calculate the probability of all the rows being added in the first seconds of a pooling cycle.
Having the application loose means that case the middleware backbone is down the operations on the database side are not affected at all…
If using Java inside the trigger to actualy publish the document to ES or IS then you have to accomodate failures to connect, slow connection times, etc… these can eventually produce locks in the database (case-by-case basis) and increase the complexity of the actual trigger itself.
The side effect of this can be slowing down the entire process…
#webMethods#Integration-Server-and-ESB#Adapters-and-E-Standards