[
https://issues.jboss.org/browse/ISPN-2038?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-2038:
-------------------------------------
Not true. Even if a single thread performs all of the RPC for a given transaction (and
this is what happens even now!) if your listener is async (and you have an async listener
thread pool of > 1 thread) it is possible that the events are handled out of order.
What you need, specifically, is the ability to register an async listener but to pass in
to that listener a mechanism of ordering the events it receives. This is what is commonly
known as "unit of order", where, in your case, the transaction id becomes the
unit of order when handling messages on the receiver.
Some JMS implementations support this, it is worthwhile checking whether HornetQ currently
supports this - it has been on their roadmap for a while now.
Single thread doing all distribution related to a transaction - to
get ORDERING
-------------------------------------------------------------------------------
Key: ISPN-2038
URL:
https://issues.jboss.org/browse/ISPN-2038
Project: Infinispan
Issue Type: Enhancement
Reporter: Sudheer Krishna
Assignee: Manik Surtani
Priority: Minor
If we have this feature were in - a single thread does all replication related tasks
related to a transaction(may be by JTA transaction id) , we will get ordering of the
messages by default.
This will be quite useful in lots of use cases where ordering of messages is necessary -
which is now achieved with SYNC replication , can also be done using ASYNC replication(IF
we can guarantee ORDERING in ASYNC with the above feature).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira