JBossDeveloper

I think what Tim's trying to say is that since we dont have a domain model that maps to our database we cant just annotate the message and messageref objects to be able to save them direct via a hibernate session. i.e. look at the messageref object and compare it with the database table, it has other fields such as channell_id and transaction_id. For this to work using Hibernate normally you'd have to add a relationship between messageref object and the destination object and the transaction object which wouldn't make sense.

It is possible to access the dialect direct, but its not well documented and i'm not sure if its usable. maybe we need a rethink, how about writing some ansii standard sql and just using JDBC, our schema isnt very complex and we should be able to do that?

"timfox" wrote:
Hi Tyronne-

Any more progress on this?

Hi Guys,
I've read the topic twice but excuse me if I've misunderstood something.
Here are my comments:
1- Using Hibernate/JPA just because Schema Export is useful isn't a sufficient argument. Schema Export is a development tool. Generated Schemas need to be reviewed/tuned by a DBA, so you cannot rely 110% on it in production
2- Using Hibernate/JPA to generate the Schema and then use pure JDBC seems weird.
3- I don't feel detyped/dynamic model will be more efficient than a pure oo domain model

If you requirements are:
- DML/DDL depending the target DB
- most efficient module in terms of performance, avoid the little overhead of ORM
Then I'd suggest you to go and use pure JDBC and write a set of fully tested DDL/DML for each database and insert a config parameter.

Anyway, if your model isn't complex, I'd suggest you to code 3 prototypes
- OO domain model + ORM
- OO domain model + JDBC
- map of map with jdbc
and test it under heavy load

I'm pretty sure the overhead of ORM will be very very small.

I'd be happy to help you to tune your ORM based prototypes.

Anthony Patricio
Hibernate/JPA support engineer.

Anthony

1- Using Hibernate/JPA just because Schema Export is useful isn't a sufficient argument. Schema Export is a development tool. Generated Schemas need to be reviewed/tuned by a DBA, so you cannot rely 110% on it in production

Tim

However, maybe I am mistaken / misinformed and such an API does not exist, in which case I imagine we need to go down the ORM route. If this is the case I would like to know if HIbernate can be configured to not cache - basically just act as a raw "translator".

well you hit 2 distinct things:
1- DDL, mainly used by Schema Export --> see my previous comment. SchemaExport uses hibernate metadatas to generate a schema creation script. (FYI metadatas is the place where you say my class Person is mapped to the PERSON table or, in your case, the PERSON table is mapped to the entity name "Person" if you don't have a real class)
2- DML. With Hibernate, you use HQL (or JPA QL), it's OO based on class and property names (associations, collections, basic properties).
2-a, if you use dynamic models, you'll have to define aliases (entity-name) instead of using class and property names). Then, in your java code, when querying, you'll use theses aliases. The HQL query will be translated in SQL
2-b if you don't like the generated SQL, if you want to tune it, you'll have to use the SQL query feature which is very close to pure JDBC...

3- about caching, you can disable all the caches.

I must admit that this is a very specific usage of hibernate, I'm pinging the core Hibernate guys to get their feelings.

Christian advices not to use the stateless session (Hibernate session with first level cache disabled).
I really think we should bench the 2 or 3 options we have.
How many tables are you using? How many joins in the queries? Will you have concurrent access?...

I agree with Anthony's assessment that using Hibernate as nothing more than a portability tool is the wrong approach. It will certainly work, and likely work well, but we have to consider the support issues going forward when a JMS application suddenly becomes a JMS + Hibernate one.

Hibernate is a good abstraction, but it can be a bit leaky when it becomes a fundamental layer of the appserver. We see this today with jBPM. While you'd win in terms of ease of portability across RDBMSs, you'd potentially lose with extra complexity for JBM.

I'd have to look more at how JBM does persistence today to see what opportunities there are for improvement besides using Hibernate.

Hibernate is a good abstraction, but it can be a bit leaky

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 guess what I'm saying is that I think the DB persistence manager is not really that important since the recommended persistence manager will be Berkeley DB. So why are we putting work into making a cross db persistence mechanism in the first place. We could keep the current code base(with only one script) and just support the internal db that we ship with, hypersonic(yuck). The messaging team wouldn't have to do any work and one script would be easy to keep up with. When users say, Hypersonic is bad, we tell them to use Berkeley DB. It seems much simpler to have two choices and much easier to support. I'd definitely vote to throw out cross db persistence in JBM.

Jay:)

my 2 cent:

Afaik from the talks I had with Tim and others from messaging you guys basically have 1 or 2 tables you are doing data inserts into - nothing fancy at all and you don't really have any "state" to carry around except single messages.

For that StatelessSession is the right thing to use if you want to use hibernate.