用JDBC直接操作Oracle AQ表会出错，必须使用Oracle专用驱动（如ojdbc8.jar）和oracle.jms.AQjmsFactory；AQ非标准JMS实现，依赖私有类，需全限定队列名（如scott.order_queue），显式设置消息属性，注意权限与超时机制。
用JDBC直接操作AQ表会出错，必须用Oracle专用驱动和oracle.jms.AQjmsFactory
oracle aq不是标准jms实现，jdk自带的jms接口无法直接连；哪怕你配置了connectionfactory类名，也会在createconnection()时报classnotfoundexception或noclassdeffounderror。根本原因是oracle aq依赖其私有jdbc扩展，比如oracle.jdbc.driver.oracledriver和oracle.jms.aqjmsqueueconnectionfactory，这些类不在标准jar里。
实操建议：
- 确保classpath包含
ojdbc8.jar（或对应版本）和aqapi.jar（Oracle 12c+已合并进ojdbc8.jar，但11g需单独引入） - 不要用
javax.naming.InitialContext查JNDI——除非你在WebLogic里配了AQ资源，否则直接new工厂更可靠 - 连接URL格式必须是JDBC格式，例如：
jdbc:oracle:thin:@localhost:1521:orcl，不能是TNS别名或LDAP地址 - 用户名密码必须是拥有
DEQUEUE/ENQUEUE权限的schema，且该schema下已运行DBMS_AQADM.GRANT_QUEUE_PRIVILEGE
AQjmsSession.createQueue()的queueName参数不是SQL对象名，而是schema.queue_name全限定名
很多人传入"MY_QUEUE"就报ORA-00942: table or view does not exist，因为Oracle AQ底层把队列映射为数据库对象，而JMS接口要求你显式指定schema上下文。它不自动继承连接用户的schema。
实操建议：
- 创建队列时用
DBMS_AQADM.CREATE_QUEUE指定queue_table和queue_name，例如：在scott下建队列order_queue，则JMS中queueName应写"scott.order_queue" - 如果队列在公共同义词下，仍需写全限定名，同义词不会被JMS层解析
- 注意大小写：Oracle默认大写对象名，若建队列时用了双引号定义小写名（如
"my_queue"），则此处也必须传"scott.my_queue"，否则找不到
发送消息必须设置JMSDeliveryMode和JMSPriority，否则Oracle可能拒绝入队
Oracle AQ对JMS属性校验比ActiveMQ等宽松但更“刻板”：它不接受null或未设值的必填字段。常见现象是send()不报错但消息永远卡在READY状态之外，或者日志里出现ORA-25207: dequeue failed, no message available这类误导性错误。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
实操建议：
- 显式调用
message.setJMSDeliveryMode(DeliveryMode.PERSISTENT)，非持久模式在AQ中不受支持 - 设置
message.setJMSPriority(4)（范围0–9），不设会触发Oracle内部默认逻辑，但某些版本会静默丢弃 - 若用
TextMessage，内容长度超过32KB需启用aqapi.jar中的LOB支持，否则抛ORA-01461: can bind a LONG value only for insert into a LONG column - 避免在消息里塞二进制数据——AQ原生支持
RAW类型，但JMS层会强制转成BLOB，容易触发隐式转换失败
监听端用AQjmsTopicPublisher或AQjmsQueueReceiver时，receive()阻塞行为与超时控制不遵循JMS规范
标准JMS里receive(long timeout)超时后返回null，但Oracle AQ的实现常因底层AQ daemon轮询间隔（默认1s）导致实际延迟远大于设定值，甚至卡死。更隐蔽的问题是：若队列启用了multiple_consumers，多个receiver可能同时收到同一消息，因为AQ的JMS封装没完全实现JMS的consumer隔离语义。
实操建议：
- 改用
receiveNoWait()+ 循环sleep，比设timeout更可控；每次sleep不超过500ms，避免累积延迟 - 消费端务必检查
message.getJMSMessageID()去重，尤其在集群部署时 - 不要依赖
onMessage()回调——AQjmsSession不实现MessageListener，强行注册会抛UnsupportedOperationException - 生产环境务必开启AQ的
schedule_propagation，否则跨schema或跨DB的消息不会自动转发，看起来像“消息丢失”
最易忽略的是权限粒度：ENQUEUE和DEQUEUE必须分别授权，且DEQUEUE权限还分ALL和OWN，后者只能消费自己发的消息——这个细节在文档里藏得深，但线上出问题时90%都卡在这儿。
