如何将JMS队列视为临时存储？

Question

I want to be able to pull and insert messages to and from a queue. Is it possible to leverage JMS features for this, or should I need create a custom data structure for this?

Please let me know if there is any other specific design pattern for a temporary storage.

Update : Since many asking for more detail, so here it is. My requirement is to store a message in a queue from which multiple clients can push the data to, and also pull the data back from it as and when required. This queue should be available to multiple clients. One message should be processed only once and if client is not able to process the data then message should return back to the queue.

Answer 1

It seems that you are asking multiple things in one question, so it might benefit you to clarify a little the individual points you need answered.

Yes, it is possible to have JMS used as a 'temporary' storage, but it depends on what you mean by that and what you need. Most JMS providers (such as ActiveMQ) allow you to do the following things on queues:

• Set a queue to durable (ie store on disk and if the queue gets restarted all messages are there) or non-durable (ie do not store on disk and if the queue gets restarted there will be no messages).
• You can set an expiry time on messages, so that if they are not picked up on time they are discarded.

This depends on what you are referring to as 'temporary storage'. A JMS queue is not a database, its a messaging system.

Regarding data structures, you can serialize both normal Java Objects in an ObjectMessage and also text messages with the TextMessage . So you can pass through XML, JSON, CSV or whatever you want. You can also include special headers which you can use for routing or other meta-information associated with the message. Again depends on what you mean by 'custom data structure'. You can also send a raw BytesMessage , or a MapMessage (key-value pairs), or a StreamMessage with different data types inside it one after the other.

If you need temporary storage in the literal sense, maybe you should look at embedded databases such as Derby or HSQLDB. I think they also have configurations to state whether data should stay in memory or go to disk after it gets too large.