5:41 a.m.
Author: ataylor
Date: 2010-01-11 06:41:10 -0500 (Mon, 11 Jan 2010)
New Revision: 8784
Modified:
trunk/examples/jms/no-consumer-buffering/readme.html
trunk/examples/jms/paging/readme.html
trunk/examples/jms/pre-acknowledge/readme.html
trunk/examples/jms/producer-rate-limit/readme.html
trunk/examples/jms/queue-selector/readme.html
trunk/examples/jms/queue/readme.html
trunk/examples/jms/scheduled-message/readme.html
trunk/examples/jms/security/readme.html
trunk/examples/jms/send-acknowledgements/readme.html
trunk/examples/jms/ssl-enabled/readme.html
trunk/examples/jms/static-selector-jms/readme.html
trunk/examples/jms/static-selector/readme.html
trunk/examples/jms/temp-queue/readme.html
trunk/examples/jms/topic-hierarchies/readme.html
trunk/examples/jms/topic-selector-example1/readme.html
trunk/examples/jms/topic-selector-example2/readme.html
trunk/examples/jms/transactional/readme.html
trunk/examples/jms/xa-heuristic/readme.html
trunk/examples/jms/xa-receive/readme.html
trunk/examples/jms/xa-send/readme.html
trunk/examples/jms/xa-with-jta/readme.html
Log:
fixed example read me's part 3
Modified: trunk/examples/jms/no-consumer-buffering/readme.html
===================================================================
--- trunk/examples/jms/no-consumer-buffering/readme.html 2010-01-09 18:26:20 UTC (rev
8783)
+++ trunk/examples/jms/no-consumer-buffering/readme.html 2010-01-11 11:41:10 UTC (rev
8784)
@@ -9,11 +9,10 @@
<h1>No Consumer Buffering Example</h1>
<p>By default, HornetQ consumers buffer messages from the server in a client
side buffer
- before you actually receive them on the client side.</p>
+ before actual delivery actually occurs.</p>
<p>This improves performance since otherwise every time you called receive()
or had processed the last
message in a MessageListener onMessage() method, the HornetQ client would have to go
the
- server to request the next message, which would then get sent to the client side, if
one was available.</p>
- <p>This would involve a network round trip for every message and really reduce
performance.</p>
+ server to request the next message involving a network round trip for every message
reducing performance.</p>
<p>Therefore, by default, HornetQ pre-fetches messages into a buffer on each
consumer. The total maximum size of
messages in bytes that will be buffered on each consumer is determined by the
<code>consumer-window-size</code>
parameter on the connection factory.</p>
Modified: trunk/examples/jms/paging/readme.html
===================================================================
--- trunk/examples/jms/paging/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/paging/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -8,13 +8,15 @@
<body onload="prettyPrint()">
<h1>Paging Example</h1>
- <p>This example shows how HornetQ would avoid running out of resources by
paging messages.</p>
- <p>A maxSize could be specified per Destination on the destinations settings
(hornetq-configuration.xml).</p>
- <p>When the buffered messages are consuming too much memory, HornetQ starts
writing messages on the file-system, and as the memory is released by message
acknowledgement or transaction commits those messages are recovered from disk and placed
in memory</p>
- <p>Acknowledgement plays an important factor on paging as messages will stay
on the file system until the memory is released</p>
-
- <p>A Queue is used to send messages point to point, from a producer to a
consumer. The queue guarantees message ordering between these 2 points.</p>
+ <p>This example shows how HornetQ would avoid running out of memory resources
by paging messages.</p>
+ <p>A maxSize can be specified per Destination via the destinations settings
configuration file (hornetq-configuration.xml).</p>
+ <p>When messages routed to an address exceed the specified maxSize the server
will begin to write messages to the file
+ system, this is called paging. This will continue to occur until messages have been
delivered to consumers and subsequently
+ acknowledged freeing up memory. Messages will then be read from the file system ,
i.e. depaged, and routed as normal. </p>
+ <p>Acknowledgement plays an important factor on paging as messages will stay
on the file system until the memory is released
+ so it is important to make sure that the client acknowledges its messages.</p>
+
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i></p>
Modified: trunk/examples/jms/pre-acknowledge/readme.html
===================================================================
--- trunk/examples/jms/pre-acknowledge/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/pre-acknowledge/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -25,7 +25,7 @@
update message will arrive soon, overriding the previous price.</p>
<p>In order to use pre-acknowledge functionality with HornetQ the session has
to be created with
a special, HornetQ specific acknowledgement mode, given by the value of
- <code>HornetQSession.PRE_ACKNOWLEDGE</code>.
+ <code>HornetQJMSConstants.PRE_ACKNOWLEDGE</code>.
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i></p>
Modified: trunk/examples/jms/producer-rate-limit/readme.html
===================================================================
--- trunk/examples/jms/producer-rate-limit/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/producer-rate-limit/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -11,7 +11,7 @@
<p>With HornetQ you can specify a maximum send rate at which a JMS
MessageProducer will send messages.
This can be specified when creating or deploying the connection factory. See
<code>hornetq-jms.xml</code></p>
<p>If this value is specified then HornetQ will ensure that messages are never
produced at a rate higher than
- the specified rate. This is a form of producer
<i>throttling</i>.</p>
+ specified. This is a form of producer <i>throttling</i>.</p>
<h2>Example step-by-step</h2>
<p>In this example we specify a <code>producer-max-rate</code> of
<code>50</code> messages per second in the
<code>hornetq-jms.xml</code>
file when deploying the connection factory:</p>
Modified: trunk/examples/jms/queue/readme.html
===================================================================
--- trunk/examples/jms/queue/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/queue/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -8,7 +8,7 @@
<body onload="prettyPrint()">
<h1>JMS Queue Example</h1>
- <p>This example shows you how to send and receive a message to a JMS Queue
with HornetQ.</p>
+ <p>This example shows you how to send and receive a message to a JMS Queue
using HornetQ.</p>
<p>Queues are a standard part of JMS, please consult the JMS 1.1 specification
for full details.</p>
<p>A Queue is used to send messages point to point, from a producer to a
consumer. The queue guarantees message ordering between these 2 points.</p>
Modified: trunk/examples/jms/queue-selector/readme.html
===================================================================
--- trunk/examples/jms/queue-selector/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/queue-selector/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -11,7 +11,7 @@
<p>This example shows you how to selectively consume messages using message
selectors with queue consumers.</p>
<p>Message selectors are strings with special syntax that can be used in
creating consumers. Message consumers
- that are thus created only receive messages that match its selector. On message
delivering, the JBoss Message
+ created with a message selector will only receive messages that match its selector.
On message delivery, the JBoss Message
Server evaluates the corresponding message headers of the messages against each
selector, if any, and then delivers
the 'matched' messages to its consumer. Please consult the JMS 1.1
specification for full details.</p>
Modified: trunk/examples/jms/scheduled-message/readme.html
===================================================================
--- trunk/examples/jms/scheduled-message/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/scheduled-message/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -8,12 +8,12 @@
<body onload="prettyPrint()">
<h1>JMS Scheduled Message Example</h1>
- <p>This example shows you how to send a scheduled message to a JMS Queue with
HornetQ.</p>
+ <p>This example shows you how to send a scheduled message to a JMS Queue using
HornetQ.</p>
<p>A Scheduled Message is a message that will be delivered at a time specified
by the sender. To do this,
simply set a HDR_SCHEDULED_DELIVERY_TIME header property. The value of the property
should be the time of
- deliver in milliseconds. </p>
+ delivery in milliseconds. </p>
- <p>In this example, a message is created with the scheduled delivery time set
to 5 seconds after.</p>
+ <p>In this example, a message is created with the scheduled delivery time set
to 5 seconds after the current time.</p>
<h2>Example step-by-step</h2>
Modified: trunk/examples/jms/security/readme.html
===================================================================
--- trunk/examples/jms/security/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/security/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -8,14 +8,14 @@
<body onload="prettyPrint()">
<h1>JMS Security Example</h1>
- <p>This example shows you how configure and use security with
HornetQ.</p>
+ <p>This example shows how to configure and use security using
HornetQ.</p>
- <p>With security properly configured, HornetQ can restrict client access to
its resouces, including
+ <p>With security properly configured, HornetQ can restrict client access to
its resources, including
connection creation, message sending/receiving, etc. This is done by configuring
users and roles as well as permissions in
the configuration files. </p>
- <p>HornetQ supports wild-card in security configuration. This feature makes
security configuration very much
- flexible and it enables fine-grained control over permissions in an efficient
way.</p>
+ <p>HornetQ supports wild-card security configuration. This feature makes
security configuration very
+ flexible and enables fine-grained control over permissions in an efficient
way.</p>
<p>For a full description of how to configure security with HornetQ, please
consult the user
manual.</p>
@@ -51,14 +51,14 @@
</pre>
<p>
- Each user has three properties available: user name, password, and roles it belongs
to. It should be noticed that
- a user can belong to more than one roles. In the above configuration, all users
belong to role 'user'. User 'andrew' also
- belongs to role 'europe-user', user 'frank' also belongs to
'us-user' and 'news-user', and user 'sam' also belongs to
'news-user'.
+ Each user has three properties available: user name, password, and roles it belongs
to. It should be noted that
+ a user can belong to more than one role. In the above configuration, all users
belong to role 'user'. User 'andrew' also
+ belongs to role 'europe-user', user 'frank' also belongs to
'us-user' and 'news-user' and user 'sam' also belongs to
'news-user'.
</p>
<p>
User name and password consists of a valid account that can be used to establish
connections to a HornetQ server, while
- roles are used in controling the access privileges against HornetQ topics and
queues. You can achieve this control by
- configuring proper permissions in
<code>hornetq-configuration.xml</code>, like in the following
+ roles are used in controlling the access privileges against HornetQ topics and
queues. You can achieve this control by
+ configuring proper permissions in
<code>hornetq-configuration.xml</code>, like the following
</p>
<pre class="prettyprint"><code>
<security-settings>
@@ -96,8 +96,8 @@
wildcards to apply certain permissions to a set of matching queues and topics. In
the above configuration
we have created four sets of permissions, each set matches against a special group
of targets, indicated by wild-card match attributes.</p>
- <p>You can provide a very loose permission control for a very general group of
destinations. Then you add more strict control
- over specific topics. By the above we define the following access rules:</p>
+ <p>You can provide a very broad permission control as a default and then add
more strict control
+ over specific addresses. By the above we define the following access
rules:</p>
<li>Only role 'us-user' can create/delete and pulish messages to
topics whose names match wild-card pattern 'news.us.#'.</li>
<li>Only role 'europe-user' can create/delete and publish messages
to topics whose names match wild-card pattern 'news.europe.#'.</li>
Modified: trunk/examples/jms/send-acknowledgements/readme.html
===================================================================
--- trunk/examples/jms/send-acknowledgements/readme.html 2010-01-09 18:26:20 UTC (rev
8783)
+++ trunk/examples/jms/send-acknowledgements/readme.html 2010-01-11 11:41:10 UTC (rev
8784)
@@ -9,11 +9,10 @@
<h1>Asynchronous Send Acknowledgements Example</h1>
<p>Asynchronous Send Acknowledgements are an advanced feature of HornetQ which
allow you to
- receive acknowledgements that messages were successfully received at the server in a
separate stream
- to the stream of messages being sent to the server.<p/>
+ receive acknowledgements that messages were successfully received at the server in a
separate thread to the sending thread<p/>
<p>In this example we create a normal JMS session, then set a
SendAcknowledgementHandler on the JMS
- session's underlying core session. We send many messages to the server without
blocking, and asynchronously
- the server calls the handler when it has successfully received each message.
+ session's underlying core session. We send many messages to the server without
blocking and asynchronously
+ receive send acknowledgements via the SendAcknowledgementHandler.
<p>For more information on Asynchronous Send Acknowledgements please see the
user manual</p>
<h2>Example step-by-step</h2>
Modified: trunk/examples/jms/ssl-enabled/readme.html
===================================================================
--- trunk/examples/jms/ssl-enabled/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/ssl-enabled/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -10,7 +10,7 @@
<p>This example shows you how to configure SSL with HornetQ to send and
receive message. </p>
- <p>Using SSL can make your messaging applications interact with HornetQ
service securely. An application can
+ <p>Using SSL can make your messaging applications interact with HornetQ
securely. An application can
be secured transparently without extra coding effort. To secure your messaging
application with SSL, you need to configure connector and acceptor as follows:</p>
<p>
Modified: trunk/examples/jms/static-selector/readme.html
===================================================================
--- trunk/examples/jms/static-selector/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/static-selector/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -26,9 +26,9 @@
</queues>
</code></pre>
- <p>Once thus configured, as this example does, the queue
'selectorQueue' only delivers messages that are selected against the filter,
i.e.,
+ <p>Once configured the queue 'selectorQueue' only delivers messages
that are selected against the filter, i.e.,
only the messages whose 'color' properties are of 'red' values can
be received by its consumers. Those that don't match
- the filter will be dropped by queue and therefore will never be delivered to any of
its consumers.</p>
+ the filter will be dropped by the queue and therefore will never be delivered to any
of its consumers.</p>
<p>In the example code, five messages with different 'color' property
values are sent to queue 'selectorQueue'. One consumer
is created to receive messages from the queue. Of the five sent messages, two are of
'red' color properties, one is 'blue',
Modified: trunk/examples/jms/static-selector-jms/readme.html
===================================================================
--- trunk/examples/jms/static-selector-jms/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/static-selector-jms/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -1,6 +1,6 @@
<html>
<head>
- <title>HornetQ Static Message Selector Example</title>
+ <title>HornetQ Static Message Selector JMS Example</title>
<link rel="stylesheet" type="text/css"
href="../../common/common.css" />
<link rel="stylesheet" type="text/css"
href="../../common/prettify.css" />
<script type="text/javascript"
src="../../common/prettify.js"></script>
@@ -22,7 +22,7 @@
</queue>
</code></pre>
- <p>Once thus configured, as this example does, the queue
<code>selectorQueue</code> only delivers messages that are
+ <p>Once configured the queue <code>selectorQueue</code> only
delivers messages that are
that match the selector; i.e. only the messages whose
<code>color</code> property is equal to <code>'red'</code>
can be received by its consumers.
Those that don't match the selector will be dropped by the queue and
therefore will never be delivered to any of its consumers.</p>
Modified: trunk/examples/jms/temp-queue/readme.html
===================================================================
--- trunk/examples/jms/temp-queue/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/temp-queue/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -8,8 +8,12 @@
<body onload="prettyPrint()">
<h1>JMS Temporary Queue Example</h1>
- <p>This example shows you how to use a TemporaryQueue object with HornetQ.
First it creates a temporary queue to send and receive a message, then delete it. Then it
creates another temporary queue and tries to use it after its connection is closed -- to
illustrate its scope.</p>
- <p>TemporaryQueue is a JMS queue that lives within lifetime of its connection.
It is often used in request-reply type messaging where the reply is sent through a
temporary destination. The temporary queue is often created as a server resource, so after
using, the user should call delete() method to release the resources. Please consult the
JMS 1.1 specification for full details.</p>
+ <p>This example shows you how to use a TemporaryQueue with HornetQ. First a
temporary queue is created to send and receive a message and then deleted.
+ Then another temporary queue is created and used after its connection is closed
to illustrate its scope.</p>
+ <p>A TemporaryQueue is a JMS queue that exists only within the lifetime of its
connection. It is often used in request-reply
+ type messaging where the reply is sent through a temporary destination. The
temporary queue is often created as
+ a server resource, so after using, the user should call delete() method to
release the resources.
+ Please consult the JMS 1.1 specification for full details.</p>
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i></p>
Modified: trunk/examples/jms/topic-hierarchies/readme.html
===================================================================
--- trunk/examples/jms/topic-hierarchies/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/topic-hierarchies/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -9,10 +9,10 @@
<h1>Topic Hierarchy Example</h1>
<p>HornetQ supports topic hierarchies. With a topic hierarchy you can register
a subscriber with a wild-card
- and that subscriber will receive any messages sent to an address that matches the
wildcard.</p>
+ and that subscriber will receive any messages routed to an address that match the
wildcard.</p>
<p>HornetQ wild-cards can use the character '#' which means
"match any number of words", and
the character '*' which means "match a single word". Words are
delimited by the character "."</p>
- <p>For example if I subscribe using the wild-card "news.europe.#",
then that matches messages sent to the addresses
+ <p>For example if I subscribe using the wild-card "news.europe.#",
then that would match messages sent to the addresses
"news.europe", "news.europe.sport" and
"news.europe.entertainment", but it does not match messages sent to the
address "news.usa.wrestling"</p>
<p>For more information on the wild-card syntax please consult the user
manual.</p>
Modified: trunk/examples/jms/topic-selector-example1/readme.html
===================================================================
--- trunk/examples/jms/topic-selector-example1/readme.html 2010-01-09 18:26:20 UTC (rev
8783)
+++ trunk/examples/jms/topic-selector-example1/readme.html 2010-01-11 11:41:10 UTC (rev
8784)
@@ -8,10 +8,11 @@
<body onload="prettyPrint()">
<h1>JMS Topic Selector Example 1</h1>
- <p>This example shows you how to send message to a JMS Topic, and subscribe
them using selectors with HornetQ, also creating 3 non durable subscribers. 2
subscriptions using selectors, and a third one that should receive the complete set of
messages.</p>
+ <p>This example shows how messages can be consumed from a topic using Message
Selectors.</p>
+ <p>Consumers (or Subscribers) will only consume messages routed to a topic
that match the provided selector</p>
<p>Topics and selectors are a standard part of JMS, please consult the JMS 1.1
specification for full details.</p>
- <p>A regular subscriber would receive every message sent to the topic, but
when you use a selector you would limit the messages you receive by the logic expression
you choose only getting the messages that will matter to your processing.</p>
+
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i></p>
Modified: trunk/examples/jms/topic-selector-example2/readme.html
===================================================================
--- trunk/examples/jms/topic-selector-example2/readme.html 2010-01-09 18:26:20 UTC (rev
8783)
+++ trunk/examples/jms/topic-selector-example2/readme.html 2010-01-11 11:41:10 UTC (rev
8784)
@@ -11,7 +11,7 @@
<p>This example shows you how to selectively consume messages using message
selectors with topic consumers.</p>
<p>Message selectors are strings with special syntax that can be used in
creating consumers. Message consumers
- that are thus created only receive messages that match its selector. On message
delivering, the JBoss Message
+ that are thus created only receive messages that match its selector. On message
delivering, the HornetQ
Server evaluates the corresponding message headers of the messages against each
selector, if any, and then delivers
the 'matched' messages to its consumer. Please consult the JMS 1.1
specification for full details.</p>
@@ -19,7 +19,7 @@
<code>'color=red'</code>, it only receives messages that
have a 'color' string property of 'red' value; the second is created
with selector <code>'color=green'</code>, it
only receives messages who have a 'color' string property of
- 'green' value; and the thrid without a selector, which means it receives all
messages. To illustrate, three messages
+ 'green' value; and the third without a selector, which means it receives all
messages. To illustrate, three messages
with different 'color' property values are created and sent.</p>
<h2>Example step-by-step</h2>
Modified: trunk/examples/jms/transactional/readme.html
===================================================================
--- trunk/examples/jms/transactional/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/transactional/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -8,11 +8,13 @@
<body onload="prettyPrint()">
<h1>JMS Transactional Session Example</h1>
- <p>This example shows you how to use a transactional Session with HornetQ. It
creates a transactional session. At first it sends out two messages and tries to receive
without session commit. Then it commits the sending session and receives only one messages
before it rolls back the receiving session. It then receives all the messages and commits
the session.</p>
+ <p>This example shows you how to use a transacted Session with
HornetQ.</p>
+ <p>Firstly 2 messages are sent via the transacted sending session before being
committed. This ensures that both message
+ are sent</p>
+ <p>Secondly the receiving session receives the messages firstly demonstrating
a message being redelivered after the session
+ being rolled back and then acknowledging receipt of the messages via the commit
method.</p>
+
- <p>Messages can be sent and received over transactional sessions. Messages in
a transactional session will not be sent or acknowledged until the session is committed.
It a session is rolled back, the produced messages will be destroyed and consumed messages
will be recovered. Please consult the JMS 1.1 specification for full details.</p>
-
-
<h2>Example step-by-step</h2>
<p><i>To run the example, simply type
<code>./build.sh</code> (or <code>build.bat</code> on windows)
from this directory</i></p>
Modified: trunk/examples/jms/xa-heuristic/readme.html
===================================================================
--- trunk/examples/jms/xa-heuristic/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/xa-heuristic/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -7,7 +7,7 @@
</head>
<body onload="prettyPrint()">
<h1>JMS XA Heuristic Example</h1>
- <p>This example shows you how to make an XA heuristic decision through HornetQ
Management Interface.</p>
+ <p>This example shows you how to make an XA heuristic decision through the
HornetQ Management Interface.</p>
<p>A heuristic decision is a unilateral decision to commit or rollback an XA
transaction branch after it has
been prepared. </p>
Modified: trunk/examples/jms/xa-receive/readme.html
===================================================================
--- trunk/examples/jms/xa-receive/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/xa-receive/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -7,16 +7,16 @@
</head>
<body onload="prettyPrint()">
<h1>JMS XA Receive Example</h1>
- <p>This example shows you how message receiving behaves in an XA transaction
in HornetQ. In an XA
- Transaction, only if the associated XAResource are commited, will the messages be
removed from the queue.
- Otherwise, the messages maybe redelivered after rollback or during the XA
recovery.</p>
+ <p>This example demonstrates receiving a message within the scope of an XA
transaction. When using an XA transaction
+ the message will only be acknowledged and removed from the queue when the
transaction is committed.
+ If the transaction is not committed the message maybe redelivered after rollback or
during XA recovery.</p>
- <p>HornetQ is JTA aware, meaning you can use HornetQ in a XA transactional
environment
+ <p>HornetQ is JTA aware, meaning you can use HornetQ in an XA transactional
environment
and participate in XA transactions. It provides the javax.transaction.xa.XAResource
interface for that
purpose. Users can get a XAConnectionFactory to create XAConnections and
XASessions.</p>
<p>In this example we simulate a transaction manager to control the
transactions. First we create an XASession
- for receiiving and a normal session for sending. Then it starts a new xa
transaction and enlist the receiving
+ for receiving and a normal session for sending. Then we start a new xa transaction
and enlist the receiving
XASession through its XAResource. We then send two words, 'hello' and
'world', receive them, and let the
transaction roll back. The received messages are cancelled back to the queue. Next
we start
a new transaction with the same XAResource enlisted, but this time we commit the
transaction after receiving the
Modified: trunk/examples/jms/xa-send/readme.html
===================================================================
--- trunk/examples/jms/xa-send/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/xa-send/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -7,9 +7,9 @@
</head>
<body onload="prettyPrint()">
<h1>JMS XA Send Example</h1>
- <p>This example shows you how message sending behaves in an XA transaction in
HornetQ. In an XA
- Transaction, only if the associated XAResource are commited, will the messages be
sent to the queue.
- Otherwise, the messages to be sent will be discarded.</p>
+ <p>This example shows you how message sending behaves in an XA transaction in
HornetQ. When a message is sent within
+ the scope of an XA transaction, it will only reach the queue once the
transaction is committed.
+ If the transaction is rolled back the sent messages will be discarded by the
server.</p>
<p>HornetQ is JTA aware, meaning you can use HornetQ in a XA transactional
environment
and participate in XA transactions. It provides the javax.transaction.xa.XAResource
interface for that
Modified: trunk/examples/jms/xa-with-jta/readme.html
===================================================================
--- trunk/examples/jms/xa-with-jta/readme.html 2010-01-09 18:26:20 UTC (rev 8783)
+++ trunk/examples/jms/xa-with-jta/readme.html 2010-01-11 11:41:10 UTC (rev 8784)
@@ -9,14 +9,14 @@
<h1>JMS XA with JTA Example</h1>
<p>This example shows you how to use JTA interfaces to control transactions
with HornetQ. JTA provides
- facilities to start and stop a transaction, enlist XA resources into a
transaction.</p>
+ facilities to start and stop a transaction and enlist XA resources into a
transaction.</p>
<p>HornetQ is JTA aware, meaning you can use HornetQ in a XA transactional
environment
and participate in XA transactions. It provides the javax.transaction.xa.XAResource
interface for that
purpose. Users can get a XAConnectionFactory to create XAConnections and
XASessions.</p>
<p>In this example we get a transaction manager from JBoss JTA to control the
transactions. First we create an XASession
- for receiiving and a normal session for sending. Then it starts a new xa
transaction and enlist the receiving
+ for receiving and a normal session for sending. Then we start a new xa transaction
and enlist the receiving
XASession through its XAResource. We then send two words, 'hello' and
'world', receive them, and let the
transaction roll back. The received messages are cancelled back to the queue. Next
we start
a new transaction with the same XAResource enlisted, but this time we commit the
transaction after receiving the