As you know, the bridge acts as a receiver from the source destination and a sender to the target destination. When async-enabled is set to true, the bridge works as an asynchronous listener to the source destination, while otherwise it acts as a synchronous receiver. In other words, the former is a push mode and the latter is a poll mode. The sync mode does batching while async mode does not. There are a couple of things that you need to consider while determining which mode is better, such as the desired QOS of the bridge, and whether you are bridging between wls destinations or a WLS destination to/from a 3rd party destination. For example, if you requires exactly-once QOS and your source destination is not a WLS JMS destination, you have to use sync mode; actually the bridge internally will switch to sync mode even if you set it to async mode.
You can find the tuning guide for the messaging bridge at
Your understanding is correct in general. The real performance will depend on your application load, and the batch size and batch interval settings of the bridge. In the sync mode, the bridge will wait for a batch to fill up before it commits a transaction. If your message traffic is slow, the bridge may spend a lot of time waiting. You need to tune your bridge for your application in order to yield the best performance. A bridge in sync mode will also use one thread per bridge instance and if you have a lot of bridge instances, we’ll need to tune your thread pool as well. The details are in the tuning guide.