Message Queuing in Oracle Database 19c
Oracle Advanced Queuing (AQ) provides enterprise message functionality across many industries and is widely used within the database itself. AQ supports both persistent and non-persistent messages, and AQ queues can be set up under different queuing models such as point-to-point and publish-subscribe to let business applications communicate with each other flexibly and reliably.
AQ asynchronously notifies interested clients about messages and database events. Messages can be asynchronously propagated between queues on the same or different databases
Interfaces to AQ include PL/SQL, JMS 1.1, JDBC, ODP.NET and OCI. Oracle WebLogic Server applications interoperate with AQ through the JMS API.
By being integrated with the database, AQ allows enqueues and dequeues to be automatically committed at the same time as other database operations without requiring the overhead of two-phase commit or XA interfaces. Standard SQL can query messages and their metadata. Indexes can be used to optimize access to messages. All operational benefits of the Oracle database such as high availability, scalability, security and reliability are applicable to the messages and queues in AQ. Oracle Dataguard, RAC, Enterprise Manager, and other Oracle technologies can be used with AQ.
For an overview on AQ and a short tutorial, please look at the following whitepaper:
Oracle Database 19c: Advanced Queuing Technical Brief (PDF)
What's New in Oracle Database 19c: AQ Sharded Queues
AQ Sharded Queues are high-performance, scalable database queues that are designed to work well in single-instance databases, RAC databases, or Exadata database machines. Sharded Queues have optimizations for JMS, large numbers of subscribers, and scalability across RAC instances.
AQ Sharded Queues make it simpler to build and deploy Microservices with transactional messaging. Asynchronous Messaging is essential for Microservices, which are defined as loosely coupled service-oriented architectures with bounded contexts. Typically, synchronous communication with blocking REST APIs is an impediment to scaling Microservices architectures.
For details on AQ-JMS Sharded Queue performance, please look at the following whitepaper: