1 Reply Latest reply on Oct 22, 2009 11:50 AM by Clebert Suconic

    Consider storing JMS destinations in their own journal insta

    Jeff Mesnil Master

      this is related to https://jira.jboss.org/jira/browse/HORNETQ-45.

      Currently, JMS resources created through the management API are not preserved on server restart.
      We need to persist them so that, when the JMS server is restarted, we redeploy the resources.

      Clebert commented that he'd prefer to use the same journal for both Core and JMS resources.
      It is possible to put everything in the same journal but I still want to provide a separate storage manager dealing only with JMS resources.
      Currently, the JournalStorageManager is creating the journal.
      We'd need to refactor that so the Journal is injected in the storage manager.
      We'd also need to add listeners called when the journal is loaded.
      Listeners would be something like:

      interface JournalLoadListener
      {
       void onRecord(RecordInfo info);
       void failedTransaction(long transactionID, List<RecordInfo> records, List<RecordInfo> recordsToDelete);
       // something for prepared tx
      }
      


      Core storage manager will deal with its set of record types and JMS will have another set.
      Storage managers would need to implement this listener so that many storage managers would be notified when the journal is loaded.

      TBH, that sounds more complex that I'd like.

      Using a separate journal instance for JMS would be simpler. Everything related to JMS would remain in the JMS layer...
      Is there any issues with using another journal that I don't see?