Release 2 (9.2)
Part Number A96587-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Application Developer's Guide - Advanced Queuing Release 2 (9.2) Part Number A96587-01 |
|
This section answers some of the most commonly asked questions about Advanced Queuing. This chapter discusses questions in the following areas:
Access messages using SQL. Messages in the queue table (either because they are being retained or because they have not yet been processed). Each queue has a view that you can use (see "Selecting the Number of Messages in Different States for the Whole Database" ).
Typically we expect the subscriber to access the messages using the dequeue interface. If, however, you would like to see processed or waiting messages, you can either dequeue by message id or use SQL.
You cannot change the sort order for messages after you have created the queue table.
The exception queue for a multiconsumer queue must also be a multiconsumer queue.
Expired messages in multiconsumer queues cannot be dequeued by the intended recipients of the message. However, they can be dequeued in the REMOVE mode once (only once) using a NULL consumer name in dequeue options. Messages can also be dequeued from an exception queue by specifying the message ID.
Expired messages can be dequeued only by specifying message ID if the multiconsumer exception queue was created in a queue table without the compatible parameter or with the compatible parameter set to '8.0'
If a latency less than 0 was specified in the propagation schedule, the job is rescheduled to run after the specified latency. The time at which the job actually runs depends on other factors, such as the number of ready jobs and the number of job_queue_processes. It may also be affected by the value for job_queue_interval. Please refer to the MANAGING JOB QUEUES chapter of the Oracle9i Database Administrator's Guide for more information on job queues and SNP background processes.
You can pick a tablespace for storing the queue table and all its ancillary objects using the storage_clause parameter in DBMS_AQADM.CREATE_QUEUE_TABLE. However, once you pick the tablespace, all IOTs and indexes created for that queue table will go to the specified tablespace. Currently, you do not have a choice to split them between different tablespaces.
In 8.1 you can associate OPS instance affinities with queue tables. If you are using q1 and q2 in different instances, you can use alter_queue_table (or even create queue table) on the queue table and set the primary_instance to the appropriate instance_id.
Yes, here is a simple rule that specifies message properties - rule = 'priority 1';
here are example rules that specify a combination of message properties and data attributes: rule = 'priority 1 AND tab.userdata.sal 1000' rule = '((priority between 0 AND 3) OR correlation = 'BACK_ORDERS') AND tab.userdata.customer_name like ''JOHN DOE'')'
Note that user data properties or attributes apply only to object payloads and must be prefixed with tab.userdata in all cases. Check documentation for more examples.
No. Registration is an OCI client call to be used for asynchronous notifications (that is, push). It provides a notification from the server to the client when a message is available for dequeue. A client side function (callback) is invoked by the server when the message is available. Registration for notification is both nonblocking and nonpolling.
To provide a mechanism for notification to all users that are currently connected. The non-persistent queue mechanism supports the enqueue of a message to a non-persistent queue and OCI notifications are used to deliver such messages to users that are currently registered for notification.
Yes, 1024 subscribers or recipients for any queue.
You can dequeue these messages by msgid. You can find the msgid by querying the queue table view. Eventually the messages are moved to the exception queue (you must have the AQ background process running for this to happen). You can dequeue these messages from the exception queue with a normal dequeue.
Only by dequeuing and enqueuing the message again. If you are changing the message payload, it is a different message.
Notification is possible only to OCI clients. The client does not have to be connected to the database to receive notifications. The client specifies a callback function which will be executed for each message. Asynchronous Notification cannot be used to invoke an executable, but it is possible for the callback function to invoke a stored procedure.
Propagation from a multiconsumer queue to a single consumer queue is possible. The reverse is not possible (propagation is not possible from a single consumer queue).
You are probably using the NEXT_MESSAGE navigation option for dequeue. This uses the snapshot created during the first dequeue call. After that the other dequeue calls generate more undo which fills up the rollback segment and hence generates 1555.
The workaround is to use the FIRST_MESSAGE option to dequeue the message. This will reexecute the cursor and get a new snapshot. This might not perform as well, so we suggest you dequeue them in batches: FIRST_MESSAGE for one, and NEXT_MESSAGE for the next, say, 1000 messages, and then FIRST_MESSAGE again, and so on.
The subscriber_types and their values are:
1 - Current Subscriber. The subscribers name, address and protocol are in the same row.
2 - Ex subscriber - A subscriber that unsubscribed but had agent entries in the history aq$_queuetable_h IOT.
4 - Address - Used to store addresses of recipients. The name is always NULL. The address is always non-NULL.
8 - Proxy for Propagation - The name is always NULL.
database proxy to local queues, address=NULL, protocol=0
database proxy to remote queues, address=dblink address, protocol=0
3rd party proxies, address = NULL, protocol = 3rd party protocol.
No, AQ does not provide this information. To get around this, the application could save this information in the message.
When the enq_time is the same for messages, there is another field called step_no that will be monotonically increasing (for each message that has the same enq_time). Hence this helps in maintaining the order of the messages. There will be no situation when both enq_time and step_no are the same for more than one message enqueued from the same session.
In Oracle9i, OMB functionality is provided in the Oracle database. So, if you are using the Oracle9i database, use the functionality offered by the database.
You do not need OMB.
With Oracle8i, use OMB in the following scenarios:
Use JMS functionality directly from the database in other scenarios.
Yes, you can specify a security policy with AQ queue tables. While dequeuing, use the dequeue condition (deq_cond) or the correlation ID for the policy to be applied. You can use "1=1" as the dequeue condition. If you do not use a dequeue condition or correlation ID, the dequeue will result in an error.
The Advanced Queuing retention feature can be used to automatically clean up messages after the user-specified duration after consumption.
You can do a dequeue with the subscriber name or by message ID. This consumes the messages, which will be cleaned up after their retention time expires.
To clean up messages for a particular subscriber, you can remove the subscriber and add the subscriber again. Removing the subscriber removes all the messages for that subscriber.
By default, the Messaging Gateway log file is in the $ORACLE_HOME/mgw/log directory. The location can be overridden by the log_directory parameter of the mgw.ora file. A new log file is created each time the MGW agent starts. The format of the log file name is "oramgw-hostname-timestamp-processid.log".
The exception messages logged to the MGW log file may include one or more linked exceptions ([Linked-exception]), which are helpful in determining the problem. A java.sql.SQLException may include an Oracle error message and possibly a PL/SQL stack trace.
The following example shows entries from a MGW log file when an invalid value (`bad_service_name') was specified for the database parameter of dbms_mgwadm.db_connect_info. This resulted in the MGW agent being unable to establish database connections.
>>2002-01-15 15:45:12 MGW AdminMgr 0 LOG Connecting to database using connect string = jdbc:oracle:oci8:@BAD_SERVICE_NAME >>2002-01-15 15:45:15 MGW Engine 0 3 Agent is shutdown. oracle.mgw.admin.MgwAdminException: [241] Failed to connect to database. SQL error: 12154, connect string: jdbc:oracle:oci8:@BAD_SERVICE_NAME [...Java stack trace here...] [Linked-exception] java.sql.SQLException: ORA-12154: TNS:could not resolve service name [...Java stack trace here...]
Use the MGW_GATEWAY view to show gateway status information. The AGENT_STATUS and AGENT_PING fields indicate the current agent status and whether it is active and responsive to pings. AGENT_STATUS progresses through the following values when the MGW agent is started:
The MGW agent may or may not automatically restart after a database shutdown or crash. The MGW agent should always be shut down before shutting down the database. If the MGW agent is running when a database SHUTDOWN NORMAL is done, the database will not shut down due to the database connections held by the MGW agent. For IMMEDIATE or ABORT the agent will not restart if the agent has time to exit normally; otherwise the agent will restart the next time the database is started.
The MGW agent establishes connections with the database and those connections prevent the database from shutting down for a SHUTDOWN NORMAL command. Call dbms_mgwadm.shutdown to shut down the MGW agent before shutting down the database.
Messaging Gateway uses job queues in the Oracle database to start the MGW agent process. At least one job queue process must be configured to execute queued jobs in the background. The gateway job is scheduled to execute immediately, but will not do so until a job queue process is available. If the gateway status remains START_SCHEDULED for an extended period of time, it may indicate that the database instance has been started with no or too few job queue processes. The Messaging Gateway holds its job queue process for the lifetime of that MGW agent session.
You should verify that the database instances have been started, with enough job queue processes so one is available for use by Messaging Gateway. A minimum value of 2 is recommended.
init.ora parameters:
JOB_QUEUE_PROCESSES specifies the number of job queue processes for each instance.
Dynamic parameters:
ALTER SYSTEM SET JOB_QUEUE_PROCESSES = <number>;
The MGW_GATEWAY view provides status information about the gateway agent. A NOT_STARTED status indicates that the agent is not running. If the MGW agent encounters a fatal error while starting or running, the LAST_ERROR_MSG field is nonnull.
Do the following:
tnsnames.ora and listener.ora are correct. Incorrect or mismatched values will prevent the listener from starting the MGW agent. process.mgw.ora are correct. Incorrect values may cause the MGW agent to terminate due to abnormal error conditions.listener.ora has been modified, the listener must be stopped and restarted before the changes will take effect.tnsnames.ora must have a net service name entry named MGW_AGENT. This entry is not needed for Messaging Gateway on Windows NT.CONNECT_DATA of the MGW_AGENT net service name in tnsnames.ora must match the SID_NAME value of the SID_DESC entry in listener.ora.MGW_AGENT net service name is set up for an IPC connection, the KEY values for ADDRESS in tnsnames.ora and listener.ora must match.tnsnames.ora or listener.ora are correct.The result code may be one of the following:
-1...An error occurred starting the Java Virtual Machine (JVM). Check the MGW log file for an entry that contains one of the following lines.
Verify that the Java version you are using is correct. Verify that your operating system version and patch level are sufficient for the JDK version. Verify that you are using a reasonable value for the JVM heap size. The heap size is specified by the max_memory parameter of dbms_mgwadm.alter_agent.
Verify that the CLASSPATH set in mgw.ora contains mgw.jar. For example:
set CLASSPATH=<ORACLE_HOME>/mgw/classes/mgw.jar
-2...An error occurred reading mgw.ora. Verify that the file is readable.
-3...An error occurred creating the MGW log file. Verify that the log directory is writeable. The default location is <ORACLE_HOME>/mgw/log.
-100...The MGW agent JVM encountered a runtime exception or error on startup.
-101...The MGW agent shut down due to a fatal error. Check the MGW log file.
This error may indicate that the database has not been started or that the environment used by the Messaging Gateway agent to connect to the database is not correct.
If the MGW log file shows the following two Oracle errors
then the gateway agent is attempting to connect to the database using a local IPC connection, but the ORACLE_SID value is not correct.
A local connection is used when dbms_mgwadm.db_connect_info is called with a NULL value for the database parameter. If a local connection is desired, the correct ORACLE_SID value must be set in the MGW agent process. This can be done by adding the following line to mgw.ora.
set ORACLE_SID = <sid_value>
Note that ORACLE_SID need not be set if dbms_mgwadm.db_connect_info is called with a nonnull value for the database parameter. In this case the value should specify a net service name from tnsnames.ora.
No, only an AQ multi-consumer queue can be used as a propagation source queue.
An MGW subscriber will be flagged as DELETE_PENDING when dbms_mgwadm.remove_subscriber is called to remove the subscriber in a nonforced manner and either the MGW agent is not running or the agent is running but unable to perform all necessary clean up action at that time.
The MGW agent tries to remove a DELETE_PENDING subscriber:
dbms_mgwadm.remove_subscriber is called and the agent is running.DELETE_PENDING subscriber.For AQ queues with RAW payload, the MGW agent can propagate messages of 32512 bytes or less. If the message size is larger than 32512 bytes, an error occurs when the agent attempts to enqueue or dequeue the message.
The DBMS_MGWADM.STARTUP procedure submits a job queue job that starts the MGW agent external process when the job is executed. The instance and force can be used to control the job and instance affinity. By default the job is set up so that it can be run by any instance.
The MGW agent propagates messages when a propagation subscriber and schedule are configured for the same source queue, destination queue, and propagation type. You can control when propagation occurs by using dbms_mgwadm.enable_propagation_schedule and dbms_mgwadm.disable_propagation_schedule. By default, the propagation schedule is enabled when it is first created.
To create a propagation job that is initially disabled, call the following APIs in the indicated order:
dbms_mgwadm.schedule_propagationdbms_mgwadm.disable_propagation_scheduledbms_mgwadm.add_subscriberIn release 9.2, the propagation schedule window parameters are not used.
The PROPAGATED_MSGS field of the MGW_SUBSCRIBERS view indicates how many messages have been successfully propagated. The EXCEPTIONQ_MSGS field indicates how many messages have been moved to the exception queue. Both these fields are reset to zero when the MGW agent is started.
If a MGW subscriber has been configured with an exception queue, the MGW agent will move messages to that exception queue the first time the MGW agent encounters a propagation failure due to a message conversion failure. A message conversion failure is indicated by oracle.mgw.common.MessageException in the MGW log file.
If a message conversion failure occurs, oracle.mgw.common.MessageException is be logged to the MGW log file. If this occurs, the MGW agent probably cannot propagate the message causing the failure, and the propagation job will eventually be disabled.
If the log file indicates that the failure is due to an exception being raised in a transformation function used for an AQ dequeue (outbound propagation) or AQ enqueue (inbound propagation), verify that the transformation function is correct.
The MGW subscriber can be configured with a propagation exception queue. If a message conversion failure occurs, the MGW agent moves that message to the exception queue and then continues processing the propagation job.
If a propagation job runs into failures during processing, the MGW agent retries up to 16 times in an exponential backoff scheme before disabling the job.
To recover from a failed propagation job, do the following:
dbms_mgwadm.reset_subscriber to reset the subscriber state. The MGW agent will attempt to recover the failed job and retry the propagation.The MAX_RETRIES parameter of AQ queues controls when AQ moves messages to an AQ exception queue for a failed dequeue attempt. The default value is NULL, which resolves to the value 5 in Oracle 9i.
If the parameter value is too small, messages in the queues can be moved into AQ exception queues if the MGW agent keeps running into failures when processing MGW subscribers. The AQ messages moved to AQ exception queues cause unrecoverable failures on the associated MGW subscribers. The MAX_RETRIES parameter for AQ queues that are used as a propagation source should be set to at least 16, and preferably a much larger value.
An MGW subscriber can be configured with a transformation to use during an AQ dequeue for outbound propagation or an AQ enqueue for inbound propagation.
Do the following:
EXECUTE to the MGW agent user or to PUBLIC on the function and the object types it references.dbms_transform.create_transformation to register the transformation.dbms_mgwadm.add_subscriber to create a MGW subscriber using the transformation, or dbms_mgwadm.alter_subscriber to alter an existing subscriber.The value passed in the transformation parameter for these APIs must be the registered transformation name and not the function name.
If a transformation function raises an exception, a message conversion failure occurs and will be indicated by an oracle.mgw.common.MessageException in the MGW log file.
The exception messages logged to the MGW log file often include a linked exception that provides additional information. If the linked exception is a java.sql.SQLException, it may include an Oracle error message and possibly a PL/SQL stack trace.
ORA-25229 is typically thrown by AQ when the transformation function raises a PL/SQL exception or some other Oracle error occurs when attempting to use the transformation.
Errors occured during processing of subscriber SUB_MQ2AQ_2 oracle.mgw.common.GatewayException: [722] Message transformation failed; queue: MGWUSER.DESTQ_SIMPLEADT, transform: MGWUSER.MGW_BASIC_MSG_TO_SIMPLEADT [...Java stack trace here...] [Linked-exception] oracle.mgw.common.MessageException: [722] Message transformation failed; queue: MGWUSER.DESTQ_SIMPLEADT, transform: MGWUSER.MGW_BASIC_MSG_TO_SIMPLEADT [...Java stack trace here...] [Linked-exception] java.sql.SQLException: ORA-25229: error on transformation of message msgid: 9749DB80C85B0BD4E03408002086745E ORA-00604: error occurred at recursive SQL level 1 ORA-00904: invalid column name [...Java stack trace here...]
Possible causes of transformation exceptions include:
EXECUTE privilege on the transformation function. It is not sufficient to grant EXECUTE to MGW_AGENT_ROLE and then grant MGW_AGENT_ROLE to the agent user. EXECUTE privilege on the transformation function must be granted directly to the agent user or to PUBLIC.EXECUTE privilege on the payload object type for the queue indicated in the exception. It is not sufficient to grant EXECUTE to MGW_AGENT_ROLE and then grant MGW_AGENT_ROLE to the agent user. EXECUTE privilege on the object type must be granted directly to the agent user or to PUBLIC.Errors occured during processing of subscriber SUB_AQ2MQ_2 oracle.mgw.common.GatewayException: [703] Failed to retrieve information for transformation mgwuser.SAMPLEADT_TO_MGW_BASIC_MSG [...Java stack trace here...]
The transformation indicated in the exception may not exist. Note that the transformation parameter of dbms_mgwadm.add_subscriber specifies the name of the registered transformation and not the name of the transformation function.
Errors occured during processing of subscriber SUB_AQ2MQ_2 oracle.mgw.common.GatewayException: [703] Failed to retrieve information for transformation mgwuser.SAMPLEADT_TO_MGW_BASIC_MSG [...Java stack trace here...] [Linked-exception] java.sql.SQLException: "from_type" is null [...Java stack trace here...]
The MGW agent user may not have EXECUTE privilege on the object type used for the from_type of the transformation indicated in the exception. It is not sufficient to grant EXECUTE to MGW_AGENT_ROLE and then grant MGW_AGENT_ROLE to the agent user. EXECUTE privilege on the object type must be granted directly to the agent user or to PUBLIC.
Errors occured during processing of subscriber SUB_AQ2MQ_2 oracle.mgw.common.GatewayException: [703] Failed to retrieve information for transformation mgwuser.SAMPLEADT_TO_MGW_BASIC_MSG [...Java stack trace here...] [Linked-exception] java.sql.SQLException: "to_type" is null [...Java stack trace here...]
The MGW agent user may not have EXECUTE privilege on the object type used for the to_type of the transformation indicated in the exception. It is not sufficient to grant EXECUTE to MGW_AGENT_ROLE and then grant MGW_AGENT_ROLE to the agent user. EXECUTE privilege on the object type must be granted directly to the agent user or to PUBLIC.
Add_subscriber and remove_subscriber are administrative operations on a queue. Though AQ does not prevent applications from issuing administrative and operational calls concurrently, they are executed serially. Both add_subscriber and remove_subscriber will block until pending transactions that have enqueued or dequeued messages commit and release the resources they hold. It is expected that adding and removing subscribers will not be a frequent event. It will mostly be part of the setup for the application. The behavior you observe will be acceptable in most cases. The solution is to try to isolate the calls to add_subscriber and remove_subscriber at the setup or cleanup phase when there are no other operations happening on the queue. That will make sure that they will not stay blocked waiting for operational calls to release resources.
CreateDurableSubscriber and unsubscribe calls require exclusive access to the Topics. If there are pending JMS operations (send/publish/receive) on the same Topic before these calls are issued, the ORA - 4020 exception is raised.
There are two solutions to the problem:
createDurableSubscriber and unsubscribe at the setup or cleanup phase when there are no other JMS operations happening on the Topic. That will make sure that the required resources are not held by other JMS operational calls. Hence the error ORA - 4020 will not be raised.TopicSession.commit call before calling createDurableSubscriber and unsubscribe call.In addition to granting the roles, you would also need to grant execute to the user on the following packages:
To use MessageListeners inside Oracle8i JServer, you can do one for the following
Call dbms_java.grant_permission ('JAVASYSPRIV', 'SYS:java.net.SocketPermission', '*', 'accept,connect,listen,resolve');
IDAP is Internet Data Access Presentation. IDAP defines the message structure for the body of a SOAP request. An IDAP message encapsulates the AQ request and response in XML. IDAP is used to perform AQ operations such as enqueue, dequeue, send notifications, register for notifications, and propagation over the Internet standard transports--HTTP(s) and e-mail. In addition, IDAP encapsulates transactions, security, transformation, and the character set ID for requests.
Internet access functionality for AQ is supported on Apache. This feature is certified to work with Apache, along with the Tomcat or Jserv servlet execution engines. However, the code does not prevent the servlet from working with other Web server and servlet execution engines that support Java Servlet 2.0 or higher interfaces.
When you send IDAP messages through SMTP, each request is a separate transaction. The IDAP request must contain <AQXmlCommit/> as part of the message request to ensure that the operation is committed.
You can create an alias to an AQ agent in Oracle Internet Directory (OID). You can use these AQ agent aliases in the IDAP document sent over the Internet to perform AQ operations. Using aliases prevents exposing the internal name of the AQ agent.
Yes, you can use your own authentication framework for authentication. HTTP POST requests to the AQ Servlet for AQ operations must be authenticated by the Web server. For example, in Apache, the following can be used to restrict access (using basic authentication) to servlets installed under aqserv/servlet. In this example, all users sending POST requests to the servlet are authenticated using the users file in /apache/htdocs/userdb.
<Location /aqserv/servlet> <Limit POST>
AuthName "Restrict AQ Servlet Access" AuthType Basic AuthUserFile /apache/htdocs/userdb/users require valid-user
</Limit></Location>
All types of events--system events, user events, and notifications on queues--can be registered with OID. System events are database startup, database shutdown, and system error events. User events include user log on and user log off, DDL statements (create, drop, alter), and DML statement triggers. Notifications on queues include OCI notifications, PL/SQL notifications, and e-mail notifications.
You can create aliases for an AQ agent in OID. These aliases can be specified while performing AQ operations-enqueue, dequeue, and notifications. This is specifically useful while performing AQ operations over the Internet when you do not want to expose an internal agent name. An alias can be used in an AQ operation (IDAP request).
Enqueue and dequeue of the message will raise the error to the application. If the error occurs during the dequeue operation, the retry count of the message is incremented. If the retry count exceeds max_retries, the message is moved to the exception queue. If the error occurs during propagation, it is handled in a manner similar to dequeue; propagation of the message will fail. It will be attempted again and the message will be moved to the exception queue when retry count exceeds max_retries for the queue.
Transformation of XML data can be done in one of the following ways:
XMLType to return an object of XMLType after applying the supplied XPath expression.XMLType object by applying an XSLT transformation to it, using the package XSLPROCESSOR.Performance is not affected by the number of queues in a table.
Yes, if it is optimized, propagation happens in batches.
If the remote queue is in a different database, we use a sequencing algorithm to avoid the need for a two-phase commit.
When a message needs to be sent to multiple queues in the same destination, it is sent multiple times. If the message needs to be sent to multiple consumers in the same queue at the destination, it is sent only once.
Creating an index on the queue table is useful in the following scenarios:
corr_id of the underlying queue table AQ$_<QueueTableName>.SELECT on the underlying queue table. An index on <QueueTableName> can be created to expedite the performance this SELECT statement.We do not have a specific performance evaluation of JMS versus the PL/SQL API. In general, the PL/SQL API is slightly better than the JMS API. The performance of the JMS and PL/SQL APIs in version 8.1.7 and higher should be comparable.
See Chapter 17 for a full discussion. The following summarizes the steps required to set up Internet access for AQ queues:
oracle.AQ.xml.AQxmlServlet class. If you are using a servlet execution engine that supports the Java Servlet 2.0 specification (like Apache Jserv), you must create a servlet that extends the oracle.AQ.xml.AQxmlServlet20 class. Implement the init() method in the servlet to specify database connection parameters.POST requests to the AQ Servlet. Only authenticated users are allowed to access the AQ Servlet.DBMS_AQADM.CREATE_AQ_AGENT. Map the AQ agent to the database users using DBMS_AQADM.ENABLE_DB_ACCESS.POST.Here are the steps for setting up your database for e-mail notifications:
DBMS_AQELM.SET_MAILHOST as an AQ administrator.DBMS_AQELM.SET_MAILPORT as an AQ administrator. If not explicit, set defaults to 25.DBMS_AQELM.SET_SENDFROM.See Chapter 17 for a full discussion. Currently, these operations are supported by Oracle Email Server 5.5 and higher. In summary, follow the steps for setting up Internet access for AQ. In addition, do the following:
DBMS_AQADM.CREATE_AQ_AGENT procedure.ORACLE_SMTP_AGENT. This user will be used to access the AQ Servlet. Also specify setEmailServerAddr or setEmailServerHost in the init() method of the AQ Servlet.$ORACLE_HOME/admin/emailrule.sql to create an AQ schema on the e-mail server database.DBMS_AQST.REGISTER_DB procedure.See Chapter 17 for a full discussion. In summary, follow the steps for setting up Internet access for AQ. The destination databases need to be set up for Internet access, as follows:
webdest.oracle.com and listening for requests on port 8081, then the connect string of the database is (DESCRIPTION=(ADDRESS=(PROTOCOL=http)(HOST=webdest.oracle.com)(PORT=8081)) If SSL is used, specify https as the protocol in the connect string. The database link is created as follows: create public database link propdb connect to john identified by welcome using '(DESCRIPTION=(ADDRESS=(PROTOCOL=http)(HOST=webdest.oracle.com)(PORT=8081))'; where user John with password Welcome is used to authenticate with the Web server, and is also known by the term AQ HTTP agent.execute dbms_aqadm.set_aq_propagationwallet('/home/myuid/cwallet.sso', 'welcome');AQPropServlet that extends oracle.AQ.xml.AQxmlServlet20 (if you are using a Servlet 2.0 execution engine like Apache Jserv) or extends oracle.AQ.xml.AQxmlServlet (if you are using a Servlet 2.2 execution engine like Tomcat). This servlet must connect to the destination database. The servlet must be deployed on the Web server in the path aqserv/servlet.
John.dbms_aqadm.schedule_propagation('src_queue', 'propdb').
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|