1 2 3 Previous Next 33 Replies Latest reply on Jan 15, 2008 8:24 AM by bershath27 Go to original post
      • 30. Re: JBM 2.0 JDBCPersistenceManager - volunteers?
        bershath27

        i truly agree with the point what Jay has highlighted. but if we're to proceed with, well then i believe Max and Anthony have shown us the best possible way to do that IMHO.

        like to know the next steps of the process.
        Tyronne

        • 31. Re: JBM 2.0 JDBCPersistenceManager - volunteers?
          timfox

           

          "jhowell@redhat.com" wrote:
          Tim, correct me if I'm wrong....
          The db persistence interface is only there so we can work out of the box. The "real" persistence that we are recommending to customers will be the file based persistence utilizing Oracle's Berkeley DB. That is going to be the persistence that we will recommend to customers, if they call and say that the db persistence runs slow.

          Because of licensing constraints, we can't ship Berkeley DB, so we ship with a db persister that utilizes hypersonic. Since we are shipping with a db persister, the thinking is that we should ship with something that plugs into many DBs.

          Since we have to work out of the box, with hypersonic, then we should just make a jdbc persister that can use all databases. So then we would have to maintain scripts, so we use an abstraction that will keep us from maintaining scripts. I agree that using hibernate, the performance may be slower. It usually is when you introduce an abstraction. But what we get for the possible performance hit is that the the messaging team doesn't have to write and maintain a script for each database.

          The question that I have is, since the db persistence manager is not the manager that will will eventually recommend to our customers, should we really need to worry about any other database, other than the one we ship with? Why would anyone use Oracle, or Mysql for JMS persistence, when it will be slower than the Berkeley DB file persister.


          I think some customers really want to use JDBC even though it will be slower - these are possibly people migrating from JBoss MQ or earlier versions of JBM who like to store their messages in a DB.

          We won't recommend JDBC persistence but I think we need to support it.



          • 32. Re: JBM 2.0 JDBCPersistenceManager - volunteers?
            timfox

             

            "bershath27" wrote:
            well then i believe Max and Anthony have shown us the best possible way to do that IMHO.


            I would tend to go with Max's recommendation of Hibernate stateless session.


            like to know the next steps of the process.


            The next step would be to build a prototype and measure it's performance.

            • 33. Re: JBM 2.0 JDBCPersistenceManager - volunteers?
              bershath27

               

              "timfox" wrote:


              like to know the next steps of the process.

              The next step would be to build a prototype and measure it's performance.


              ok . i will start it from my end.

              thanks
              Tyronne Wickramarathne

              1 2 3 Previous Next