This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Originally posted by Jonathan Harker: I have a JMS queue and I want that only one message is processed at a time, I am using MDBs. By processing I mean Start to Finish not just delivey of message to the Bean. What should I do ?
MDB is asynchornus messaging.
So, you should use JMS, not MDB.
Java Developer, Thailand
It is asynchronous in the sense that the message sender doesn't have to wait for the message to be processed before it can send a new message. What I want that messages be processed sequentially. If we have MDBs, there would be multiple instances (generally) so a sequential processing would not be possible. To this point of time, I can think of only one way of doing that - max beans in free pool = 1
do you have a cluster? then each cluster member will have an instance and your approach does not work in this case...
Joined: Jul 21, 2004
... my solution was to start an external process that consumes the message and call's a method of an stateless session bean. Failover was not nescessary because we did monitor the queue (alert if the number of messages pass a limit).
Good Point. When we have multiple concurrent processes, and given that normally we use the default isolation level, aren't the chances of integrity constraint violation in the database higher? This is the reason why I was looking at serializing the stuff.
Joined: Jul 21, 2004
hmmm - what's the default isolation level? READ_COMMITTED I think? If your messages rarely change the same data I would'nt have fear that there are too many rollbacks, if any. We serialized because there was a application dependency between some messages.
I had the same problem, to process the message sequentially in a cluster yet using MDBs. It was only achieved at the database level. The message was inserted into the DB, there was a Timestamp field to indicate the insertion time. A thread picks up one message at a time from DB and processes it.
The solution had performance drawbacks but I guess we would be able to live with it.