So I have a new architecture that is being created at my work to take an application inhouse and fully rewrite it. There will be times that we will be integrating with the old system and the new system as we migrate new functionality one piece at a time. I have reviewed Spring/Hibernate/iBATIS and really think that Hibernate is an excellent persistence solution. So I have received some of the following questions regarding Hibernate. I would really love some help answering these as I have spent the last few days scouring the web and my documents for answers.

1) In creating TO/DTO/VO (whatever you want to call them) from the DAO, many of the frameworks have to use some mechanism to load these objects from the configuration files that map the data. It appears from the FAQs that this is handled by reflection and/or by CGLIB, is this correct? Are these configuration files loaded into objects at app startup, so the creation and abstraction of data presented in these mapping files very minimal? Is there continual performance hits with every query for the conversion of HQL results into the Data Objects through Hibernate and reflection (if that is what is used)?

2) Can a result from a query be cached so that if a developer wanted to create multiple different DTO/TO/VO from the same ResultSet, it would not re-execute the query?

3) They asked about how transactions can span multiple EJBs and whether or not they have to be explicitly start/stop. From the "J2EE Development without EJB" transaction chapter, it really appears that it would be dependent on the BO because it would be the coordinator of calls to the DAO and possibly making multiple calls to different DAOs to accomplish a business rule that needs to be handled as a single transaction. Wouldn't you just place your transaction handling for Hibernate into your BOs instead of at the DAO level?

4) Is there a tally of the number of downloads for Hibernate?

5) Last but not least, besides known issues such as learning a new framework (which I don't believe to be a real reason not to use something better), are there any cons to Hibernate as opposed to just straight JDBC?

I really appreciate your help in answering these questions. And also a thanks to all Hibernate information, which is really abudant at this time.

jay

1.) I don't get your question

2.) Yes, query results can be cached. Pretty much everything can be cached in Hibernate.

3.) The recommended approach is to do the transaction handling in some interceptor-like approach (A Servlet Filter, Session Facades using CMT or some Appserver-Interceptor).

4.) No, Hibernate is completely free under the LGPL - see http://www.hibernate.org/196.html

5.) This is a long issue. ORMs in general are not very ideal for "mass operations" like massive deltes, updates, etc. even though H3 is much more convenient in that are through bulk updates and deletes. Also an ORM is often overkill when you have a purely "tabular" application, without a need for a real domain model.

I don't have much time to elaborate further - consider getting a copy of Hibernate in Action, especially your architectural questions are pretty well covered there.

1. The TO/DTO/VO are usually referred as POJO in Hibernate world. They are one to one representation of table definition in the database. You will need to use some tool like Middlegen to create these POJOs. If you are using HQL to query the database, HIbernate will give back to you these POJO or collection POJOs filled with the data. Hibernate may not need to use Reflection as it knows the POJO structure and query results fully. The population of these POJOs is unavoidable no matter which persistence technology you use.

2. Hibernate does not have a concept of ResultSet unless you are using SQL. As long as you are using HQL you will get back either POJO, collection of POJOs or custom defined TO (Transfer Object). Hibernate has this powerful feature of calling constructor of TO as part of the query ( I am very impressed with this feature).

As far as the caching goes, Hibernate provides a session which is a primary cache and is available by default. I myself have not experimented yet secondary cache .

3. It sounds like you want to know how a transaction spans in EJB environment: When a call to session EJB is made, depending upon your transaction settings like TRANSACTION_REQUIRED, a transaction is started in App server. When yu call a beginTransaction method on session, Hibernate joins a current running transaction. A call to endTransaction on session is just detaching itself from EJB's transaction. The EJB transaction keeps running until end of the business method defined in EJB. This way you have a choice to call 'setRollBackONly()' to rollback current transaction in case of an exception.

By the way this is not explained in 'Hibernate in Action' in great details.

4. no comments

5. I have found one drawback: (not sure if they are addressed in Hibernate 3, I am suing 2.1)
It would be nice if lazy attribute can be set dynamically at run time so that caller method has full control.
There could be more but there are work-arounds for those.