1 2 Previous Next 29 Replies Latest reply on Oct 5, 2005 2:50 PM by starksm64

    Hibernate-based JMS PM

    timfox



      Steve Ebersole wrote: (moved from dev list)


      > I am starting to look at a Hibernate-based persistence-manager for JBoss
      > Messaging. Couple of questions:
      >
      >
      >
      > 1) From what I could see, a ?full schema? would encapsulate the
      > information from both the PersistenceManager and the StateManager.
      > Anything else I missed?
      >
      > 2) At how high of a priority should I place inter-operability with
      > the current schema used by the JDBC-based state/persistence-managers?
      > Should it strictly use the same schema already in use by the JDBC
      > counterparts; or is it ok to do what seems reasonable here if that
      > differs? Two things in particular from my initial look:
      >
      > a. I noticed that the JMS_MESSAGE is using a composite primary
      > key; I?d prefer to use surrogate keys.
      >
      > b. Based on the definition of the JMS_MESSAGE table, I would assume
      > that the entire javax.jms.Message gets serialized into the MESSAGEBLOB
      > column. Based on that assumption, I would further assume then that
      > **all** messages need to get loaded from the database in order to apply
      > message selectors. It should be possible to store the parts of the
      > message individually; is it ok to explore that path? Or do the
      > internals already assume that the message selectors get applied to
      > in-memory instances?
      >

        • 1. Re: Hibernate-based JMS PM
          timfox

          > I am starting to look at a Hibernate-based persistence-manager for JBoss
          > Messaging. Couple of questions:
          >

          A Hibernate persistence manager is certainly one option. Although I'm not 100% sold that it's not overkill for what we have - our schema is very simple. It's definitely something we should consider though.

          >
          >
          > 1) From what I could see, a ?full schema? would encapsulate the
          > information from both the PersistenceManager and the StateManager.
          > Anything else I missed?
          >
          > 2) At how high of a priority should I place inter-operability with
          > the current schema used by the JDBC-based state/persistence-managers?

          The current thought is that we don't have compatibility with jboss mq schema. We would provide migration scripts to migrate persistent message data or other state if customer's require it.

          > Should it strictly use the same schema already in use by the JDBC
          > counterparts; or is it ok to do what seems reasonable here if that
          > differs? Two things in particular from my initial look:
          >
          > a. I noticed that the JMS_MESSAGE is using a composite primary
          > key; I?d prefer to use surrogate keys.

          JMS_MESSAGE table? Do you mean the MESSAGES table?

          >
          > b. Based on the definition of the JMS_MESSAGE table, I would assume
          > that the entire javax.jms.Message gets serialized into the MESSAGEBLOB
          > column. Based on that assumption, I would further assume then that
          > **all** messages need to get loaded from the database in order to apply
          > message selectors. It should be possible to store the parts of the
          > message individually; is it ok to explore that path? Or do the
          > internals already assume that the message selectors get applied to
          > in-memory instances?

          The entire message is currently serialized as a blob but this is only a temp. fix. The idea would be that all fields that can participate in a selector expression would be available as columns, so message selection can be done on the db level.

          >

          • 2. Re: Hibernate-based JMS PM
            timfox

            Hang on one sec....

            Steve-

            Is your question about the JBoss MQ persistence manager or the JBoss Messaging persistence manager?

            I've got a feeling you're talking about the former...........

            • 3. Re: Hibernate-based JMS PM
              sebersole

               

              Is your question about the JBoss MQ persistence manager or the JBoss Messaging persistence manager?

              I am referring to whatever you want to call whatever is kept in the CVS module named 'messaging'. I assume this is the "pre-redesign" code.

              I have not seen the new code, thus nor its db-schema, so I cannot really give you give you whether this is overkill or not.

              But I can tell you that if it is anything like the old code and you are still manually maintaining:
              1) schema generation scripts for each database; and
              2) the DML statements to use for each database
              then use of Hibernate hardly seems overkill for this fact alone.

              • 4. Re: Hibernate-based JMS PM
                timfox

                The current CVS module "messaging" = JBoss MQ, the current production quality JMS provider.

                JBoss Messaging is in the "jms" module in head, this is the new JMS provider which will eventually take over from JBoss MQ.

                You're question referred to JBoss Messaging, so I answered it on the basis you were talking about JBoss Messaging, when you were actually referring to JBossMQ.

                The ironic thing is we are actually looking at using hibernate for our persistence manager too, but that's a different story....

                • 5. Re: Hibernate-based JMS PM
                  sebersole

                   

                  "timfox" wrote:
                  >
                  A Hibernate persistence manager is certainly one option. Although I'm not 100% sold that it's not overkill for what we have - our schema is very simple. It's definitely something we should consider though.

                  see previous.

                  "timfox" wrote:
                  >
                  JMS_MESSAGE table? Do you mean the MESSAGES table?

                  Ok, somewhere in between ;) I am talking about the JMS_MESSAGES table.


                  "timfox" wrote:
                  >
                  The entire message is currently serialized as a blob but this is only a temp. fix. The idea would be that all fields that can participate in a selector expression would be available as columns, so message selection can be done on the db level.


                  • 6. Re: Hibernate-based JMS PM
                    sebersole

                     

                    "timfox" wrote:
                    The current CVS module "messaging" = JBoss MQ, the current production quality JMS provider.

                    JBoss Messaging is in the "jms" module in head, this is the new JMS provider which will eventually take over from JBoss MQ.

                    Ok.
                    jms = messaging
                    messaging = MQ

                    got it ;)

                    "timfox" wrote:

                    The ironic thing is we are actually looking at using hibernate for our persistence manager too, but that's a different story....

                    I can help out with that also.

                    • 7. Re: Hibernate-based JMS PM
                      • 8. Re: Hibernate-based JMS PM

                        Another recent discussion:
                        http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg64592.html
                        There are plenty of others.

                        There is a discussion somewhere in this forum started by Ivelin on this very issue.

                        • 9. Re: Hibernate-based JMS PM
                          sebersole

                          Cool, thanks. That gives some background/context.

                          BTW, I do agree with Gavin that ORM is overkill here from the perspcetive of having essentially indexed lobs. However, I can also see benefit in Hibernate usage (even in the current state) just from a schema maintenance/evloution perspective. E.g. no more crazy externalized prop bundles.

                          But I don't think that these necessarily need be stored as indexed lobs. Hence one of my initial questions about adherence to the existing db-schema. As we move to a more normalized schema, Hibernate usage makes more sense. Even more I think it makes much, much, much sense to move away from the indexed lob schema soo that you can properly apply selectors to the db query for restriction.

                          I also saw a discussion about system recovery. Not much you can do there while everything is stored in-total in a lob. But as we normailize this, there are many more options open regarding how we might recovery the system.

                          • 10. Re: Hibernate-based JMS PM
                            timfox

                             

                            "steve.ebersole@jboss.com" wrote:

                            I can help out with that also.


                            That sounds great. The current JBoss Messaging schema is still subject to change so it might be worth letting it settle first. We could definitely do with some hibernate expertise though.
                            Let's see what Ovidiu says when he gets online.

                            • 11. Re: Hibernate-based JMS PM
                              sebersole

                              Well it might make sense to get "some hibernate expertise" onboard *before* the schema settles down ;)

                              • 12. Re: Hibernate-based JMS PM

                                 

                                "steve.ebersole@jboss.com" wrote:
                                Even more I think it makes much, much, much sense to move away from the indexed lob schema soo that you can properly apply selectors to the db query for restriction.


                                This is misunderstanding number 1.

                                The persistence is not a live source of data. It is a recovery log in the event of a crash.
                                Selectors are run against the objects in memory not the database.

                                • 13. Re: Hibernate-based JMS PM

                                   

                                  "adrian@jboss.org" wrote:

                                  The persistence is not a live source of data.


                                  I did joke with Gavin at one point about creating a JMS facade over hibernate.
                                  This is pretty much what OracleAQ is :-)

                                  • 14. Re: Hibernate-based JMS PM
                                    sebersole

                                    So after reading some of this background, it sounds like JBossMQ (messaging module) is basically in maintenance/bug-fix mode. So I'll leave it up to y'all: given that fact, what (if any) work makes sense here in relation to Hibernate and this module?

                                    1) nothing
                                    2) new Hibernate-based PM
                                    3) replace existing PMs with a new Hibernate-based PM
                                    4) other?

                                    1 2 Previous Next