This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Comment

but the question was more than one node in a cluster environment. The JdbcChannelMessageStore does some synchronization with its idCache when used from more than one thread.

But my setup is more the one jvm on different machines. As far as I can see the JdbcChannelMessageStore in such a scenario can not do any synchronzation to prevent the same message being poll from two different nodes at the same time.

Comment

Yes I read it. And I aware of the problems handling queues on DBMS. But with external MQs you lose some nice operational aspects / features.

We have developed a more specialized implementation of a message store and the datebase gives us a transparent view of how many messages are in which queue, how long messages are waiting, to which customer a message belongs and so. Even an adminstrative task like "please retry the order for customer x" is just a simple sql update.

I'm not sure if one can get features like that with MQ solutions, even if you render your messages in XML on the store. The possibilities to
query and manipulate messages are limited.

At the moment we are using mysql innodb with row level locking by doing a select .. for update.

One thing that causes trouble is updating the last modified timestamp on message groups all the time. Is that really nessesary?