Managing Your Applications 6-13
■
Does not force an acknowledge of client acknowledged sessions, ensuring that no messages are lost for queues and durable subscriptions that require reliable
processing.
When you close a session, all associated producers and consumers are also closed.
6.5 Managing Destinations
The following sections describe how to create and delete destinations:
■
Section 6.5.1, Dynamically Creating Destinations
■
Section 6.5.2, Dynamically Deleting Destinations
6.5.1 Dynamically Creating Destinations
See the following topics for information about creating destinations dynamically:
■
Chapter 7, Using JMS Module Helper to Manage Applications
■
Section 6.6, Using Temporary Destinations The associated procedures for creating dynamic destinations are described in the
following sections.
6.5.2 Dynamically Deleting Destinations
You can dynamically delete JMS destinations queue or topic using any of the following methods:
■
JMSModuleHelper class see Chapter 7, Using JMS Module Helper to Manage
Applications
■
Administration console
■
User-defined JMX application The JMS server removes the deleted destination in real time, therefore, its not
necessary to redeploy the JMS server for the deletion to take effect. The associated procedures for dynamically deleting destinations are described in the following
sections.
6.5.2.1 Preconditions for Deleting Destinations
In order to successfully delete a destination, the following preconditions must be met:
■
The destination must not be a member of a distributed destination. For more information, see
Chapter 9, Using Distributed Destinations.
■
The destination must not be the error destination for some other destination. For more information, see
Section 6.1.2.2, Configuring an Error Destination for Undelivered Messages.
If either of these preconditions cannot be met, then the deletion will not be allowed.
Note: If you want to issue the close method within an
onMessage method call, the system administrator must select the Allow Close In OnMessage check box when configuring the
connection factory.
6-14 Programming JMS for Oracle WebLogic Server
6.5.2.2 What Happens when a Destination is Deleted
When a destination is deleted, the following behaviors and semantics apply:
■
Physical deletion of existing messages — all durable subscribers for the deleted destination are permanently deleted. All messages, persistent and non-persistent,
stored in the deleted destination are permanently removed from the messaging system.
■
No longer able to create producers, consumers, and browsers — once a destination is deleted, applications will no longer be able to create producers, consumers, or
browsers for the deleted destination. Any attempt to do so will result in the application receiving an InvalidDestinationException — as if the
destination does not exist.
■
Closing of consumers — all existing consumers for the deleted destination are closed. The closing of a consumer generates a ConsumerClosedException,
which is delivered to the ExceptionListener, if any, of the parent session, and which will read Destination was deleted.
When a consumer is closed, if it has an outstanding receive operation, then that operation is cancelled and the caller receives a null indicating that no
message is available. Attempts by an application to do anything but close a closed consumer will result in an IllegalStateException.
■
Closing of browsers — all browsers for the deleted destination are closed. Attempts by an application to do anything but close a closed browser will
result in an IllegalStateException. Closing of a browser implicitly closes all enumerations associated with the browser.
■
Closing of enumerations — all enumerations for the deleted destination are closed. The behavior after an enumeration is closed depends on the last call before the
enumeration was closed. If a call to hasMoreElements returns a value of true, and no subsequent call to nextElement has been made, then the enumeration
guarantees that the next element can be enumerated. This produces the specifics. When the last call before the close was to hasMoreElements, and the value
returned was true, then the following behaviors apply:
– The first call to nextElement will return a message.
– Subsequent calls to nextElement will throw a
NoSuchElementException.
– Calls to hasMoreElements made before the first call to nextElement
will return true.
– Calls to hasMoreElements made after the first call to nextElement
will return false. If a given enumeration has never been called, or the last call before the close was
to nextElement, or the last call before the close was to hasMoreElements and the value returned was false, then the following behaviors apply:
– Calls to hasMoreElements will return false.
– Calls to nextElement will throw a NoSuchElementException.
■
Blocking send operations cancelled — all blocking send operations posted against the deleted destination are cancelled. Send operations waiting for quota will
receive a ResourceAllocationException.
■
Uncommitted transactions unaffected — the deletion of a destination does not affect existing uncommitted transactions. Any uncommitted work associated with
Managing Your Applications 6-15
a deleted destination is allowed to complete as part of the transaction. However, since the destination is deleted, the net result of all operations rollback, commit,
etc. is the deletion of the associated messages.
6.5.2.3 Message Timestamps for Troubleshooting Deleted Destinations
