SQL JMS works through polling. At periodic intervals it performs a query on the database to see if there are any messages waiting to be delivered to its local clients. By default, this polling occurs at 20 second intervals. This means that messages have an average latency of 10 seconds (average latency is half of the polling interval, as long as messages are sent at random times).

Decreasing the polling interval decreases the average latency. However, decreasing the polling interval also increases the frequency of queries from each client, thereby increasing the database load. For example, if the polling interval is halved to 10 seconds, Oracle ATG Web Commerce doubles the number of queries that it makes in the same period of time. If there are many Oracle ATG Web Commerce servers running SQL JMS against the same database, this can add up to a significant load on the database.

So if the database load is too high, the administrator should increase the polling interval on the Oracle ATG Web Commerce servers to decrease the number of queries each server is making. This increases latency, making some messages take longer to get from sender to receiver, but decreases the load on the database.

The polling interval is set in the messagePollSchedule property of the /atg/dynamo/messaging/SqlJmsProvider component:

messagePollSchedule=every 20 sec in 10 sec

Note: While latency is affected by the polling interval, overall system throughput should remain unchanged. Each time a query performs a poll, it reads in all messages waiting for that client. For example, if a message is being sent every second, and the polling interval is set to 20 seconds, every poll reads 20 messages, yielding an effective throughput of 1 message/second, with an average latency of 10 seconds. But if the polling interval is set to 30 seconds, the average latency increases to 15 seconds, but every poll reads 30 messages, again yielding a throughput of 1 message/second.

So, administrators should be aware that they are trading low latency for high database load, or high latency for low database load. But overall throughput is not affected by the polling interval.