13.3. Factors to Note When Implementing a Custom Message Store

  • 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 setUndelivered and 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.
  • The 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 DBConnectionManager.
  • 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.