activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Fernandez <>
Subject Re: Maintaining Message Uniqueness in a Queue
Date Tue, 29 Sep 2009 11:16:17 GMT

Prior to sending a message, your scheduler can use a QueueBrowser w/selector
to peek at the queue and make sure a message with the same entity id as the
one about to be sent doesn't already exist. 

Or your consumer can use a selector to fetch any other messages on the queue
that have an entity id that matches the one just received.

But there are obvious performance implications with the above.  


itamara wrote:
> hi AMQ users
> <p />
> What is the best way to ensure Message Uniqueness in a Queue?
> <p />
> <u>I'm having the following architecture:</u><br />
> A single Scheduler (a quartz scheduled job) is periodically checking a DB
> for entities to update, for each entity-to-update it uses a single Sender
> to send an Update Message with a property holding the entity ID.<br />
> The Sender references an ActiveMQQueue destination and a Spring's
> JmsTemplate over a PooledConnectionFactory.<br />
> The Consumers - MessageListeners in a Spring's
> DefaultMessageListenerContainer container - receive a message and do their
> onMessage, which may involves updating the DB.<br />
> <br />
> I wish to avoid more then one Consumer updating the same entity
> simultaneously, as it will result in DB errors.<br />
> I thought the Scheduler should account for this synchronization, so upon
> resolution of the entities to update, it tags them in order to know not to
> update them again - a tag that is removed when update is finished. But as
> errors may occur, this tag is taken in account only for a certain period
> of time. This makes the situation, in which the queue contains two
> messages with the same entity ID, possible.<br />
> Which may cause exactly what I'm trying to avoid.
> <p />
> How do I pull it off?<br />
> I thought knowing which messages are currently in the queue could help the
> Scheduler decide.<br />
> What about the message ID? Can it help here?<br />
> I could also expire the message, but it is not accurate. I might throw
> away messages for no good reason.<br />
> Maybe it is better to do this synchronization elsewhere?
> <p />
> Thanks a lot for any help or thoughts.

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message