Due to company policy we (my small team) couldn't use queue manager in the past (the only allowed was Websphere MQ, but there was no budget for it). We've implemented queues using database. Our applications are database centric implemented in .NET. Recently this have been changed - we can use ActiveMQ or Rabbit. We've started thinking about migrating our queues but haven't decided yet which will be used.
It appeared that it is not so straightforward as it seem to be initially. We have few scenarios when we check if message is in queue using business key to avoid repetition. For example: when impatient user sends application for credit card twice (Send button clicked twice) because he don't see status change yet. We are responsible for the backend and we don't have control over client application.
Current implementation is: take user name and search within the queue if in the recent hour there was a request to obtain credit card by this user. It is quite easy to search in database. If match is found then exception is raised instead of placing message in queue. I still don't know how to do this with queue manager, I couldn’t find any information about this. I've found only some information about using message id, but in our case repeated message will have different one.
Is it possible to check if message is already in queue using some business data?
A college of mine found a solution. Currently we have queue implemented in a single database table with following data: msg_type, msg_key (this is the business key we need to be unique), msg_body, status, request_time, processed_time, retry_count and error_code.
The idea is following: this table will still be used for the purposes of deduplication only and queue manager for the purposes of queueing only (no deduplication functionality).
So we will remove unnecessary data from table. Remaining fields are: msg_type and msg_key.
Algorithm:
Our service receives request
Check if message is repeated with business key in the table. If it is then exception is raised.
Put message in queue and new message key into the table
This is just an idea. It is not yet implemented. Quite possible that this simple model will require some fixes.