1 2 3 Previous Next 31 Replies Latest reply on Feb 6, 2007 5:51 PM by Clebert Suconic

    JMS specific columns in DB

    Tim Fox Master

      Currently there are a few JMS specific columns in the database, e.g.

      JMS_MESSAGE table:
      destination
      reply_to
      correlation_id
      jms_type

      As part of http://jira.jboss.com/jira/browse/JBMESSAGING-739 I am considering removing those columns and just storing those values as core headers in the message.

      E.g. there would be a core header called JBM.JMS.Destination (or whatever), which had destination as its value.

      Having no JMS specific stuff in the db schema would have the advantage of enabling us to more cleanly support other message formats (e.g. AMQP) without changing the schema.

      It would also remove any JMS dependencies from JDBCPersistenceManager.

      Comments please?

        • 1. Re: JMS specific columns in DB
          Jeff DeLong Master

          Is this table required to support persistent queues?

          • 2. Re: JMS specific columns in DB
            Tim Fox Master

            JMS_MESSAGE stores messages which logically live in either JMS queues or JMS durable topic subscriptions.

            • 3. Re: JMS specific columns in DB
              Clebert Suconic Master

              You will probably need to store the header on the database anyway, right?

              I guess putting this to a single field is not going to eliminate the dependency anyway as you still need the information.

              Those fields are nullable anyway... if using any other protocol in the future we could just keep them NULL.

              Maybe if you want to separate things you could add the word JMS_ to these fields then it's clear what they are for.

              • 4. Re: JMS specific columns in DB
                Tim Fox Master

                If we're going to allow for them being null in the future may as well get rid of them now.

                I don't want a load of garbage in the db.

                • 5. Re: JMS specific columns in DB
                  Jeff DeLong Master

                  Might this information be useful to a human that is looking at messages that are sitting in a queue? It would be easier to read from a table than from the message header.

                  • 6. Re: JMS specific columns in DB
                    Clebert Suconic Master

                    These fields are Nullable anyway now.

                    I just don't like the idea of composed fields on the DB.

                    I prefer having the DB self documented.

                    Maybe it's something I inherited from the days I was a consultant working with business systems.

                    • 7. Re: JMS specific columns in DB
                      Tim Fox Master

                      The thing is, JBoss Messaging is supposed to be a generic messaging system.

                      Currently the DB schema has a depenency on JMS, which is wrong.

                      If we support AMQP for example, are we going to add 10 more fields AMQP_Fluxfactory, AMQP_WibbleQuotient etc?

                      I don't think so.

                      All the generic properties will still be columns, e.g. delivery count, blah blah

                      • 8. Re: JMS specific columns in DB
                        Tim Fox Master

                        Also if don't get rid of them now, it will be very hard to do so later on.

                        Since people may have written other systems / processes which rely on them.

                        I don't want to be in a situation where we end up with a crappy schema we have to live with for ever.

                        • 9. Re: JMS specific columns in DB
                          Clebert Suconic Master

                          Well... do as you wish...

                          I would prefer a separate table.. (1 to 1 relationship) or the extra fields. Composed fields are worse than these extra fields IMO.

                          • 10. Re: JMS specific columns in DB
                            Tim Fox Master

                             

                            "jeffdelong" wrote:
                            Might this information be useful to a human that is looking at messages that are sitting in a queue? It would be easier to read from a table than from the message header.


                            Getting rid of the JMS specific fields doesn't preclude the above.

                            It's quite possible that you could write a PersistenceManager implementation that stores headers (whether JMS or not) in a different table where they could be looked at by a human.

                            This would probably be hideously slow, but someone may want it.

                            • 11. Re: JMS specific columns in DB
                              Tim Fox Master

                              Well... with your logic, eventually you would end up with 100 column tables, some columns null, some not depending on which particular message type is used.

                              Yuck, no thanks :)

                              If people really want that kind of perverse monstrosity they can write a JDBCPersistenceManager implementation that does that ;)

                              • 12. Re: JMS specific columns in DB
                                Ovidiu Feodorov Master

                                 

                                Tim wrote:

                                As part of http://jira.jboss.com/jira/browse/JBMESSAGING-739 I am considering removing those columns and just storing those values as core headers in the message.

                                E.g. there would be a core header called JBM.JMS.Destination (or whatever), which had destination as its value.


                                Keeping information like "destination" in its own main table field will speed up queries, isn't it? Otherwise, you'll need to use a JOIN instead of a simple SELECT.

                                Stuffing non-generic information as message headers will impact performance. It's difficult to say how much, without proper measuring, though.


                                Tim wrote:

                                I don't want to be in a situation where we end up with a crappy schema we have to live with for ever.


                                This is what migration utilities are for. We won't have to live forever with it, we will just have to go through the trouble of writing a migration tool. We need to do this while migrating from 1.0 to 1.2 anyway.

                                Personally, I don't believe in the "perfect generic design" that "fits every possible case". We need to have a plan for evolution, not perfection, which is unattainable.

                                Could you please jot down the schema, as you think it should be, before going ahead and changing code?

                                • 13. Re: JMS specific columns in DB
                                  Clebert Suconic Master

                                   

                                  "Ovidiu" wrote:
                                  Keeping information like "destination" in its own main table field will speed up queries, isn't it? Otherwise, you'll need to use a JOIN instead of a simple SELECT.


                                  It's even worse...


                                  If you use composed fields... and if you need eventually to perform a JOIN...

                                  you will need to do something like
                                  WHERE SUBSTRING(COMPOSED_FIELD,1,5) = "DESTINATION"


                                  or something like that...


                                  Besides... if you need to support a different system, you change PersitenceManager, or implement a new one.

                                  Also...

                                  Tim wrote:
                                  Well... with your logic, eventually you would end up with 100 column tables, some columns null, some not depending on which particular message type is used.


                                  If you have 100 systems... it's better to have 100 columns than a single column with 100 substrings to deal with. :-)

                                  also.. you could have something pluggable that would enable/disable fields creation according to used features. (if that happens some day)

                                  • 14. Re: JMS specific columns in DB
                                    Aaron Walker Newbie

                                    Can't you implement the Persistence for a specific message type (JMS, AMQP,etc) as a strategy in the Persistence Manager and then you can have a custom schema per message type implementation. So as you add support for different messaging systems you just add a persistence strategy for it.

                                    Just a thought, might be maintenance hell though.

                                    --Aaron

                                    1 2 3 Previous Next