Advantage of AQ over Weblogic Queue
A reader, September 18, 2017 - 9:43 am UTC
So will this approach(ie. using AQ from the app) have any significant advantage over the old poller-JMSqueue combination ?
In the old architecture the MDB picked the message from the JMS Queue but now it will have to connect through a foreignServer/datasource to the remote database ---will this get rid of any potential advantage of not using the poller?
September 18, 2017 - 12:53 pm UTC
"In the old architecture the MDB picked the message from the JMS Queue but now it will have to connect through a foreignServer/datasource to the remote database"
You've completely lost me there ;)
What exactly are you changing?
Clarification
A reader, September 19, 2017 - 6:09 am UTC
Old architecture:
APP-->DB-->Poller-->Weblogic JMS Queue-->MDB
New proposed architecture:
APP-->Advanced Queue in DB-->MDB
I wanted to know if the profit in getting rid of the poller will be lost because now the MDB will have to connect to the DB instead of the JMS queue in weblogic.
September 19, 2017 - 3:49 pm UTC
And what exactly is MDB? An Oracle Database?
A reader, September 20, 2017 - 6:00 am UTC
MDB : Java Message Driven Bean. It is deployed in the same weblogic where the JMS Queue is and reads from it. In the new approach it will be pointed to the AdvancedQ.
September 20, 2017 - 2:41 pm UTC
OK. I'm not familiar with Java Message Driven Beans. But typically when you connect two queues together, when you enqueue on one the other dequeues straight away. No need for you to write a poller.
So I would expect this to use less resources. But, as always, you need to test in your environment to see what really happens.
Option
Racer I., September 21, 2017 - 11:16 am UTC