"jhowell(a)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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119620#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...