Hello,

I'm currently trying to re-design a project to use Hibernate2. The system is handling complex objects, objects built by other objects (as usual).

Layer description

I have the following conceptual layers:

* presentation
* middle
* business
* integration

1. Presentation

Contains the system UI components and controllers.

2. Middle

A layer that should hold as a strong interface against the business object. The target is to be able to switch the system to use PJO as well as EJB. A JAR-archive will hold either a EJB session bean implementation or PJO implementation.

3. Business

Business rules/controllers for the system. Business objects/Entity Beans (switch by changing a JAR-archive).

4. Integration

Data access objects, (connection pool), Hibernate session management, transaction management etc.

The only classes (today) that uses Hibernate2 is the data access objects. At the beginning of each persistency method (insert/update/delete etc.) in the DAO's a session is retrieved from a "SessionManager" implementing the "Thread Local" pattern. The session is returned/closed at the end of each persistency method. Transaction management is handled manually by explicitly calling session.beginTransaction();.

Sample workflows

First I have to give a example of a complex object. Imagine the following object structure:

[A] 1--* [B] Instance A contains zero or many instances of class B
[B] 1--* [C] Instance B contains zero or many instances of class C
[B] *--* [D] Instance B contains zero or many instances of D, and vice versa
[B] *--* [E] Instance B contains zero or many instances of E, and vice versa

1. Create a complexe object

1.1 Create the different object (A, B, C, D, E) and assemble them together
1.2 Call through middle tier, business tier and to the topmost object DAO (class A)
1.3 insert in DAO for class A is called and all objects are persisted due to cascade

2. Load complex object (manual lazy loading)

2.1 Query db for GUID's corresponding to SQL query
2.2 Call through middle tier , business tier and to the topmost object DAO
2.3 load(A.class, GUID) is invoked and whole object structure is returned

3. Modify state of some object in the complex object.

3.1 Change some property in one or several object
3.2 Call through middle tier, business tier and to the topmost object DAO
3.3 Call Hibernate2 saveOrUpdate()

4. Delete an object in the complex object

4.1 Locate the object in the complex object and remove it from its container (set, list etc.)
4.2 Call through middle tier, business tier to the topmost DAO
4.3 update is invoked on the topmost object to associate the complex object with the current session
4.4 Explicitly call Hibernate2 delete on the object to remove (by locating its DAO)

Some issues to illustrate:

* How to always keep the complex object state synchronized with database?

* A complex object state can be modified several times before anything is persisted with database. When a new object is added or removed the changes should be persisted right away. Will a session.save()/session.delete() persist the modifications?

* How to manage transaction spaning over several DAO's?

* The only time I need to re-associate the complex object in UI is when I would remove an object from the complex object why? When I load an complex object, add an object C for exampel and call [i]session.save()[/] in DAO no exception is raised even though the complex object should be seen as a transient object?

Any suggestions is most helpful!

Kind regards, Andreas Eriksson

Andreas,

* How to manage transaction spaning over several DAO's?

I recommend to have a look at the Spring Framework's lightweight transaction and DAO support, with dedicated support for Hibernate, JDO, and JTA including a Hibernate transaction strategy, a JTA transaction strategy, programmatic and declarative transaction demarcation, support classes for Hibernate DAO implementations, etc. For a start, check out the article at http://hibernate.bluemars.net/110.html

Generally, Spring should meet your requirements nicely, as it provides a generic IoC bean container with AOP capabilities for wiring up POJOs, with special support not only for transactions and DAOs but also for accessing EJBs and implementing EJBs. Note that most parts of Spring are individually reusable in a library style, although they work nicely within a Spring application context, of course.

Juergen
Spring Framework developer
http://www.springframework.org

I will hava a look at the Spring framework!

Is there any suggestions in terms of system architecture how to implement this particular framework?

Regards, Andreas

Another issue is:

* How do I use Spring framework when accessing more than one database i.e. using more than one SessionFactory?

Regards, Andreas

As wiring up a Spring application context works via named bean instances, be it application objects or resources, setting it up multiple session factories is straightforward. Your DAOs can receive different session factory instances by specifying different bean references. Of course, you will need JtaTransactionManager as strategy, as you require distributed transactions.

On the occasion, I've just revised the Spring article in the community area. It documents Spring 1.0 M1 now, to be released *today*. New sections illustrate typical resource definitions, both for the single database case (in section 2) and for a multiple database scenario (in section 7).

Juergen

That's great!

Is there on the agenda to provide an example desktop application using Spring and Hibernate2 framework? The only demo application I've seen involves web components which in turn handles sessions a bit different.

Kind regards, Andreas

From a Spring middle tier point of view, desktop applications are not that different from web applications. As section 8 of the article shows, you can load a Spring XML application context definition with multiple ApplicationContext implementations, e.g. within a web app or from a file or from the classpath. As long as you don't define web-dependent beans, such a context and its beans can be reused in any environment.

Obviously, a middle tier within a desktop application cannot have dependencies on a J2EE container. So a JndiObjectFactoryBean definition for fetching a DataSource from the container's JNDI needs to be replaced with with a local DataSource definition (I've just added a respective example to section 2 of the article).

A desktop application will also need to use HibernateTransactionManager as transaction strategy, as the container's JTA subsystem is obviously not available. In all other respects, the middle tier will behave the same: For example, a Hibernate Session will always be bound to the lifetime of a transaction. In a desktop application, there will only be one main thread with one transaction at the same time, but that doesn't matter.

The typical scope of a transaction is a method invocation on a business facade, matching declarative transactions via AOP proxies nicely, and being particularly appropriate for server applications. You can define any scope programmatically via TransactionTemplate though, even spanning user think time in a desktop application.

Juergen

Thank you Juergen!

I will give Spring a try :-)

Is there anyway to contact you in terms of guiding?

Kind regards, Andreas

> I will give Spring a try :-)

Andreas,

I hope you'll like it :-)

> Is there anyway to contact you in terms of guiding?

Unfortunately, I'm leaving for a 4 week trip to Australia tomorrow, so I guess I can't keep up my 24 hour response times that people are used to ;-)

Feel free to ask on one of the forums at http://sourceforge.net/projects/springframework/ - or join the user mailing list. There are various people with Spring and Hibernate experience that should be able to help with any issue you might come across.

Juergen