JMS only – provides a SQL interface to unsubscribe a topic for the current Adaptive Server session.
msg_unsubscribe::=msgunsubscribe
(subscription_name [with {remove | retain}])
subscription_name::=basic_character_expression
is the name of the subscription to which you are subscribing. A basic_character_expression.
removes or retains the durable subscription from the JMS message provider.
Tells the JMS messaging provider to stop holding messages published to the topic registered as “subscription_1”:
select msgunsubscribe('subscription_1')
Before you specify a subscription with msgsubscribe or msgunsubscribe, you must register the subscription with sp_msgadmin. This example registers the durable subscription “subscription_1”:
sp_msgadmin 'register', 'subscription', 'subscription_1', 'my_jms_provider?topic=topic.sample,user=user1,password=pwd', 'Supplier=12345', null, 'durable1', 'client1'
msgunsubscribe stops any current subscription for the current Adaptive Server session to the endpoint and filter specified by subscription_name. It returns a 0 if it succeeds, or 1 if it fails.
If you specify with retain, the connection to the JMS messaging provider is terminated so that another subscription can connect, using the same subscriber client_id specified in the subscription. The durable subscriber remains defined within Adaptive Server and within the JMS message provider. If you specify with remove, the durable subscriber definition is removed from the JMS message provider. The default value is with retain.
When a user logs out of Adaptive Server, all subscriptions in that Adaptive Server session become unsubscribed. The effect is same as running msgunsubscribe using the with retain option.
When you unsubscribe a durable subscription using with remove, the subscriber definition is removed from JMS message provider, causing all the messages held by the subscriber definition to be missed:
<login>
select msgsubscribe('subscription_1')
select msgconsume('subscription_1')
...
select msgconsume('subscription_1')
select msgunsubscribe('subscription_1' WITH REMOVE)
<logout>
----Messages published to the topic registered as subscription_1 are no
----longer held by the JMS provider
<login>
select msgsubscribe('subscription_1')
select msgconsume('subscription_1')
...
select msgconsume('subscription_1')
select msgunsubscribe('subscription_1' WITH REMOVE)
In a separate scenario, a SQL session releases a subscription so that another session can consume messages. This example shows Session 1 releasing the subscription, so that Session 2 can begin consuming from it.
Session 1 |
Session 2 |
|---|---|
select msgunsubscribe
('subscription_1' WITH RETAIN)
selectmsgconsume ('subscription_1')
...
selectmsgconsume ('subscription_1')
select msgunsubscribe
('subscription_1' WITH RETAIN)
|
|
|
select msgsubscribe('subscription_1')
select msgconsume('subscription_1')
...
select msgconsume('subscription_1')
select msgunsubscribe('subscription_1'
WITH RETAIN)
|
The following example shows msgsubscribe used before the application logic is ready to read the messages that force the JMS client to hold messages. The application subscribes:
select msgsubscribe ('subscription_1')
The client consumes the message multiple times, and uses other application logic not related to messaging. It is then ready to read messages, and it receives all the messages that have arrived since msgsubscribe was called:
select msgconsume('subscription_1')
select msgconsume('subscription_1')
The client application is finished with this subscription, and unsubscribes:
select msgunsubscribe('subscription_1')
