additional.page

---
title: Additional Information
sort_info: 30
--- name:overview

# Stomp 1.0 - additional information
Stomp 1.0 - additional information

--- name:content 

This page contains some additional information regarding Stomp protocol version 1.0 (not contained in the specification):

{menu: {used_nodes: fragments}}

#Transaction Handling

Stomp uses named transactions so that many transactions can concurrently occur at the same time. 

The client specifies the name and it is unique to that client.

so: 

	BEGIN
	transaction: tx1
	
	^@

then you can ack or send using the transaction

	ACK
	message: ID:19283:wheeeee:1234
	transaction: tx1
	
	^@


	SEND
	destination: /queue/a
	transaction: tx1
	
	hello queue a!
	^@

	ABORT
	transaction: tx1
	
	^@

Would "undo" the ack and send

#Character Encoding

We need to acknowledge character encoding and set some expectations. Much of this is taken from suggestions by SER (whom I don't otherwise know).

First, make header names required to be legal [XML element names](http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-Name). This makes a lot of sense.

Second, specify the default encoding is UTF-8. This makes ASCII a nice subset for telnet purposes. Add an encoding attribute to the CONNECT and CONNECTED frames. The server *should* use the same encoding the client requested on the CONNECT, defaulting to UTF-8 if nothing was specified, but if the client requested an encoding which the server cannot handle, it *must* send back the encoding it will use to handle the session (assuming it could understand the CONNECT frame, of course =)

#Ack Modes
The default message acknowledgement (when the server can consider the message to have been consumed by a client) is to treat it as acknowledged as soon as it is transmitted. An alternate is to require the client to acknowledge the message explicitely. Amongst other things this offers transactional message consumption and prevents flooding the client to the point of a crash and losing a pile of messages.

To handle this the client may specify and ack header in a subscription request. The default is "auto" the alternate value (there may be more later) is "client". If "client" is used the client must send an ACK frame with the message-id from the message, which may also have a transaction header with an open transaction identifier.

	SUBSCRIBE
	ack: client
	destination: /queue/a
	
	^@

	ACK
	message-id: ID:12345
	
	
#Stomp JMS Bindings

When using the Stomp Protocol with [StompConnect](http://stomp.codehaus.org/StompConnect) or a JMS provider there are some additional Stomp headers and semantics which are useful to know. In terms of JMS semantics Stomp supports the same ack modes unless the messages are exchanged within a transaction via BEGIN/COMMIT/ABORT

###Standard JMS Message Headers

The following standard JMS Headers are mapped to Stomp as follows; so these headers can be added to a SEND command when sending messages


<table>
<tr><th>Stomp header</th><th>JMS header</th><th>Description</th></tr>
<tr><td>correlation-id</td><td>JMSCorrelationID</td><td>good consumes will add this header to any responses they send so that entire conversations can be correlated</td></tr>
<tr><td>expires</td><td>JMSExpiration</td><td>the expiration time of the message</td></tr>
<tr><td>persistent</td><td>JMSDeliveryMode</td><td>whether or not the message is persistent</td></tr>
<tr><td>priority</td><td>JMSPriority</td><td>the priority on the message</td></tr>
<tr><td>reply-to</td><td>JMSReplyTo</td><td>the destination you should send replies to</td></tr>
<tr><td>type</td><td>JMSType</td><td>sets the type of the message</td></tr>
</table>

###Subscription headers

You can use an SQL 92 selector whenever you subscribe using the *selector* header

	selector:location = 'London' and sex = 'M'

When subscribing for a topic you can specify the header

	no-local:true

This will disable local messages. Namely messages published over the Stomp connection will not be received by this topic subscription.

###Durable Topic Subscribers

If you wish to create a _durable topic subscriber_ you will need to do the following

+ set the _client-id_ header on the CONNECT to a globally unique String for the Stomp connection
+ set the _durable-subscriber-name_ header on the SUBSCRIBE command.

The combination of the *client-id* and *durable-subscriber-name* uniquely identifies the durable topic subscription. i.e. after you restart your program and re-subscribe, the Broker will know which messages you need that were published while you were away