Your implementation can use
addMessage to derive a message classification scheme. If the classification is not defined, then it is up to the individual implementation of the
MessageStore to determine for itself how it will store the message. Furthermore, the classification is only a guide: your implementation can ignore this field if need be.
It is up to the implementation as to whether or not the
MessageStore imposes any kind of concurrency control on individual messages so always use the
removeMessage operation with care.
Do not use the
setDelivered commands or other associated operations unless you are sure they are applicable. This is because the
MessageStore interface supports both audit trail and re-delivery functionality.
org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl class provides the default implementation of the message store. The methods in this implementation make the required database connections via a pooled database manager, called the
MessageActionGuide and the
MessagePersister actions override the message store implementation.
The MessageStore interface does not currently support transactions. Any use of the message store within the scope of a global transaction will, therefore, be uncoordinated.
The implication of this is that each
MessageStore update or read will be undertaken separately and independently.