PL/SQL Call Back function is never called

Question

Hi, I have a AQ set to run a PL/SQL Call Back procedure, but the procedure is never called.
Oracle version is 11.2.0.2 Standard Edition
When I query aq$<queue>, the MSG_STATE column is always "ready".
This is the queue creation script
begin
  DBMS_AQADM.CREATE_QUEUE_TABLE ( queue_table => 'POLERMESSAGE',
                                  queue_payload_type => 'POLER_MESSAGE',
                                  multiple_consumers => TRUE );
  DBMS_AQADM.CREATE_QUEUE( queue_name => 'POLER_QUEUE',
                           queue_table => 'POLERMESSAGE');
  dbms_aqadm.add_subscriber( queue_name => 'POLER_QUEUE',
                             subscriber => sys.aq$_agent( 'POLER_RECIPIENT', null, null ) );    
  dbms_aq.register ( sys.aq$_reg_info_list( sys.aq$_reg_info('POLER_QUEUE:POLER_RECIPIENT',
                                                             dbms_aq.namespace_aq,
                                                             'plsql://tr',
                                                             HEXTORAW('FF')) ) ,
                       1 );    
  DBMS_AQADM.START_QUEUE(queue_name => 'POLER_QUEUE');    
end;
/This is the content of "tr" procedure
create or replace
procedure tr ( context raw,
                       reginfo sys.aq$_reg_info,
                       descr sys.aq$_descriptor,
                       payload raw,
                       payloadl number)
as
  dequeue_options dbms_aq.dequeue_options_t;
  message_properties dbms_aq.message_properties_t;
  message_handle RAW(16);
  message poler_message;
BEGIN
  dequeue_options.msgid := descr.msg_id;
  dequeue_options.consumer_name := descr.consumer_name;
  DBMS_AQ.DEQUEUE(queue_name => descr.queue_name,
                  dequeue_options => dequeue_options,
                  message_properties => message_properties,
                  payload => message,
                  msgid => message_handle);
  insert into lxtr values ( Nvl( To_Char(message.PolerMsgNro ), 'ooops' ), systimestamp ) ;
  commit ;
end tr;If I query sys.reg$, I see it registered there:
SQL> select subscription_name, location_name, status, state from sys.reg$;
SUBSCRIPTION_NAME
LOCATION_NAME
   STATUS     STATE
"SPARCS"."POLER_QUEUE":"POLER_RECIPIENT"
plsql://tr
        0         0I was working, until I re-compiled (don't ask...) the trigger that enqueue the message
This is the section of the trigger (post insert for each row) that do the enqueuing. It seems to be working, since it is enqueuing. The issue is the dequeue.
DECLARE
  enqueue_options dbms_aq.enqueue_options_t;
  message_properties dbms_aq.message_properties_t;
  message_handle RAW(16);
  message poler_message;
  err varchar2(2000);
BEGIN
    message := poler_message(PolerMsgId,  PolerMsgNro );
    dbms_aq.enqueue(queue_name => 'POLER_QUEUE',
                    enqueue_options => enqueue_options,
                    message_properties => message_properties,
                    payload => message,
                    msgid => message_handle);
END;If I run the code below, message is cleanly dequeued
declare
  dequeue_options      dbms_aq.dequeue_options_t;
  message_properties   dbms_aq.message_properties_t;
  message_handle       RAW(16);
  message              poler_message;
BEGIN
  dequeue_options.consumer_name := 'POLER_RECIPIENT' ;
  dbms_aq.dequeue( queue_name => 'POLER_QUEUE',
                   dequeue_options       => dequeue_options,
                   message_properties    => message_properties,
                   payload               => message,
                   msgid                 => message_handle);
  COMMIT;
END ;Can anyone please give me any hints on what should I do next. There is nothing on the alert log...
Thank you in advance,
Tiago

Answer 1

1) Very few PL/SQL programmers would consider it good form to have procedures with excessive numbers of parameters. In any language, though, it's possible to write poor code.
2) Initially, you're right-- the performance of properly defined SQL statements via JDBC is little different than the performance of PL/SQL stored procedures. Frequently, however, SQL statements in Java applications do not take advantage of bind variables, which will significantly limit their scalability. Maintaining SQL statements in client applications makes it significantly more difficult on the support side-- if you find a bug in a stored procedure, you can fix the bug in one place-- if you find a bug in embedded SQL, you have to fix the code everywhere the client is deployed. Maintaining PL/SQL stored procedures also makes optimization easier-- frequently your DBA will be able to boil down a stored procedure to a couple of SQL statements and vastly improve performance (i.e. INSERT INTO <<table name>> SELECT <<column list>> from <<other table>> rather than looping over a cursor doing single-row inserts). Finally, PL/SQL stored procedures enable reuse-- when the next application wants to access the database, it doesn't have to rewrite your SQL.
3) If the alternative to the bind variables (?'s) is a bunch of literals, I'll spend the extra time writing the code for the tremendous increase in scalability.
4-6) You can certainly pass classes from Java to PL/SQL and back. You can also write Java stored procedures, rather than writing PL/SQL stored procedures). Oracle has been one of the leading proponents of Java.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC