Hi all,

I'm implementing a test app in Hibernate and have set up some things like so. I have a web command that calls a service, which then calls a dao, which in turn, deals with my Hibernate layer - I'm assuming from what I've read in many places, this is somewhat standard.

Doing reads via this approach is working great. No problems. However, it came time for me to do an insert and that was a different story. I read a great book called 'The data model and resource book' - http://www.amazon.com/exec/obidos/ASIN/0471380237
So I patterned quite a bit of my design from it. It has a notion of a primary entity, which it calls a Party. From Partys, you can have various users, organizations, etc...

This falls into my model like so. My action class calls a service - in this case a user registration service. From there, this service calls my individual daos. To create a user login, i have something like so in the service and dao:



As for my design, I do not create my session outside the DAOs and pass it in - I've read about many session create/tear down issues, which I might directly have to addres here. And I've also tried to read a bunch about things being too fine-grained, hoping I could strike a reasonable balance. I haven't included my .hbm.xml files cuz I don't think this is something that really requires that much detail (I could be wrong tho).

So my question - finally - then is this. By just these two examples above, would you rate this as too fined grained? And if so, then what might be a good way to do this via service and dao patterns respectively?

My machines that I'm testing this on are a Powerbook G4 1Ghz/1GB ram/5400 rpm int HD, running postgres 7.4. An insert like this touching about 12 tables takes roughly 5-7 seconds - our registration test is quite hefty, but not run very often.

My staging machine is a Athlon 2Ghz/512MB ram/7500 rpm int hd running postgres 7.4. It averages for the same insert about 2.2 seconds, obviously due to the fact of the cpu and hd speed.

TIA

Yup, I guess so..



Intriguing. It' the same book the ofbiz guys used as basis for their data model, right? Now, considering that you have the book and I don't, can you explain what is the purpose of this Party entity?

As for your code, it looks alright to me.



IMHO, this is a mistake. Do your session and transaction management in your service layer, not in the DAO:s.



Umm, I don't know what you mean here. Hibernate claims to support a fine grained domain model nicely, i.e. that you can very well have lots of small objects without sucky performance. However, there is no recommendation that you must keep transactions as short as possible (i.e. essentially autocommit).



The granularity of your domain model looks fine to me.



That looks somewhat slow, yes. Personally, I would initially concentrate on the following:

1. Proper transaction management. I.e. don't run every friggin insert in its own transaction, operations that belong together should be done in a single transaction. This will improve safety as well as performance, as the db will always be in a consistent state from the viewpoint of the application. Typically, in a web application, you can do all db operations for a single http request in a single transaction.

2. Check that the database is correctly indexed. This obviously mostly affects read performance, but if you have too many indexes your write performance will suffer.

3. Enable batch updates (see Hibernate reference manual).

4. Not a performance suggestion per se, but if you don't use spring, you owe to yourself to check it out. Spring has quite a lot of nice support code to make life with hibernate easier. Also, using spring your code gravitates toward a "best practices" architecture almost by itself, IMHO.

Exactly where I got the book and party entity from. I was reviewing ofbiz for a project a year or so back and started looking into their entity model. At the time I didn't really have any good books or articles on how to structure people and organizations - I had run into this issue many times in the past and never really found a very satisfying solution.

According to the book and ofbiz - since they pretty much have a stratight translation from the book to their entities - a Party can represent a person, organization, a automated process, a receiver or sender, etc. It's really more of a, I think, db kinda normalization issue where tie the entity id to its own separate table vs. embedding it in one with various attributes.

At first I didn't really see much value in this. But, as I started working things out more and introducing more tables like 'electronic address' (email, web addr, etc), 'telecomm' (phone, fax, etc) and a table called 'contact_mechanism' which ties the various parties to their respective modes of contact, it all started coming together. Ofbiz has visio and also a gif of their ER diagrams. If you check this out you'll see how party can be pretty central. Also, check out the contact mechanism table to; their data model is pretty big.



Ok, this is good. I've been thinking about this and when it comes down to it, you're right, the transaction is a business decision and if there are any sql exceptions, then I can wrap them in a top level JTA trans and recover from that. Good.



I guess since I was making my transactions probably too fined grained - i.e., create a person, commit, create a organization, commit, create a user login, commit, etc... So that was prob more my question and your other point answered it.



I think this is a biggie and where I will focus my attention first.



Yah, I haven't really given it any indexes yet, so I will keep that in mind.



Yah, I think these are already enabled.



Ya know, I've read about Spring quite a bit, but unfortunately, I went in pretty deep with Struts, so I think I'm stuck with it. Anyway, thanks for the suggestions, this is exactly the kind of stuff I was looking for. Cheers!

Note that Spring can nicely serve as middle tier framework with Struts for the web tier. This is actually a pretty popular combination: Have a look at the JPetStore version that comes with Spring, it has alternative Spring web MVC and Struts web layers. Matt Raible's AppFuse uses Struts for the web tier plus Spring for the middle tier too.

Essentially, you can reap all off Spring's middle tier benefits while sticking to your Struts web tier; Spring and Struts are by no means mutually exclusive. Another pretty popular combo is WebWork2 and Spring, for example used in Atlassian's Confluence and Javablogs. Beyond web apps, Spring is also used for the middle tier of standalone Swing applications.

Juergen