Feature Enhancment Description

Jean-Francois Poilpet: Finally, almost all the points below have been reached in HiveTranse Open Source project, which is a generic transaction framework for HiveMind, which currently supports JDBC and Hibernate, and is planned to support JTA in the near future.

Jonas Maurus: If you read the text below (most of which is obsolete), please keep in mind that Hibernate 3.0+ completely switched to unchecked runtime exceptions, so Spring's Hibernate 2.x/3.x support through HibernateTemplate-Objects adds much less value IMHO.

-- JimmiDyson 2004-09-15 14:19:45

Hibernate is one of the most widely used O/R persistence APIs used today. Its only common sense to provide services to support this software.

Session (as Hibernate calls a DB connection) management is a cross-cutting concern, as is transaction management, so HiveMind can be utilised effectively to remove the need to write your own code for this.

Proposed Solution

Using Session proxy and SessionFactory proxy services, a connection to the database can be established simply by retrieving the Session proxy from the Registry. The Session proxy can be written to support any model, and by implementing the correct interfaces, automatic closure of the session can be achieved when using the threaded (recommended) or pooled models. The SessionFactory service would be a singleton, although multiple implementations of the SessionFactoryProxy could be declared. This would enable the developer using the Hibernate services to open database connections to different databases, running on different servers.

The SessionFactoryProxyFactory (horrible name...) would take as an optional parameter the path to a Hibernate config file. This would allow for multiple singleton SessionFactoryProxies to be declared, referencing different databases.

The SessionProxyFactory would require the appropriate SessionFactoryProxy to be set-serviced in the construct element.

The hivemodule.xml would contain the following:

{{{<service-point id="HibernateExceptionCoordinator" interface="org.apache.hivemind.hibernate.HibernateExceptionCoordinator">

</service-point> <service-point id="SessionFactoryProxyFactory" interface="org.apache.hivemind.ServiceImplementationFactory">

</service-point> <service-point id="SessionFactoryProxy" interface="net.sf.hibernate.SessionFactory">

</service-point> <service-point id="SessionProxyFactory" interface="org.apache.hivemind.ServiceImplementationFactory">

</service-point> <service-point id="SessionProxy" interface="net.sf.hibernate.Session">

</service-point>}}}

This would then be used to get the database Session (already opened) just like getting any other service:

Session s = (Session) reg.getService("SessionProxy",Session.class);

Need to think more about the TransactionInterceptor - any ideas would be very welcome.

Another solution to the Hibernate support is to use the ThreadLocalStorage and a singleton SessionSource to hold the Session for the thread. This could limit the end-developer to just one Session per thread, which is fine in most situations, but doesn't give the flexibility that should be given by using the Hibernate - HiveMind combination.

Discussion

I would like to add some additional request here.

A recurrent problem (at least for me but I suppose I am not the only one) when using Hibernate API is that almost EVERY method can throw HibernateException which is checked. Personnally I prefer to use checked exceptions only for business, and unchecked (runtime) exception for "technical" problems. Hence using Hibernate obliges me (and others) to put an infamous try{}catch(){throw new RT;} in all my DAO methods!

As far as I know in Spring framework, some "template" class (as it is called in Spring) has been created to change HibernateException in most calls into a Runtime exception.

I think it would be good to offer the same kind of service in Hivemind.

Unfortunately, I could not find any "powerful" way to implement that (in a generic way by proxies, for instance). The fact is that MANY Hibernate interfaces (SessionFactory, Session, Query, Criteria...) have methods throwing HibernateException.

This makes me better understand the way it has been implemented in Spring: one Template class that combines all Session API + other common API from other classes, but it seems to me that it reduces the possibilities of Hibernate for the developer.

-- JamesCarman

Maybe we should start up a new page to discuss a generic transaction framework for HiveMind. We should come up with a set of common transaction services which can be implemented in different "flavors" (i.e. HiveMind, JTA, JDBC, JDO, etc.). This framework would include the transaction interceptor which would allow for configuration of transaction requirements (requires new, required, a la EJB) and for rollback exception types (aside from the default, which includes only runtime exceptions). Any thoughts?

Requirements

Jean-Francois Poilpret: I would like to suggest gathering here a list of requirements that a Hivemind-Hibernate integration solutions should meet. After thinking about it (I am also currently working on implementing such a solution, as several others do as well), I came out with the following -preliminary- list:

  1. Possibility to configure Hibernate in any suitable user-defined way; ie, no obligation on config file name and location (do not use Hibernate defaults)
  2. Possibility to handle connections to more than one database; ie, multiple SessionFactory could be used, each with its own configuration

  3. Transparent handling of transactions: maybe something ala EJB: declarative transaction demarcation (Required, RequiresNew...), automatic rollback on exceptions (like EJB -RT exceptions only- or not -all or some exceptions?). Probably this point would need further discussions...

  4. Transparent XA transaction support: since we want multiple database support, this means that XA transactions must be supported as well. However, I do not have much experience in the area of XA transactions with Hibernate.
  5. Programmatic way to handle transaction rollback/commit: this can be useful (but this must not be the mandatory way to manage transactions, personnally I always prefer automatic/declarative transaction handling)
  6. Provide full access to Hibernate "Session" power (no limited interface of it): one idea is to leveredge Hibernate knowledge of users base. This means, for instance, that in my DAO implementation classes I shall get access to a service (injected by Hivemind) that implements Session interface. I think using a "HibernateTemplate" as in Spring is not as good as it seems, because it can "hide" some useful Hibernate possibilities.

  7. Allow configuration fo which exceptions must rollback transactions (Nice to have?): I find this idea interesting, but it should not be mandatory, I mean this could make the configuration hard to read and maintain. I think there should be acceptable defaults if we do not provide any config for it.
  8. Possibility to map checked HibernateException into RT exceptions (Nice to have, maybe out of scope): Actually, I am the one who initiated such a request. But having it means creating a "Hibernate Template" like in Spring, which means selecting a subset of Hibernate methods, possibly removing some not so often used -but still useful- capabilities. After thinking again about that problem, I had an idea of a more generic way to handle the problem of checked Vs. unchecked exceptions. But this is not related to the hibernate integration in Hivemind (although developers might use it in this context). Since I just started with this idea I will expose it later in a separate thread.

HibernateSupport (last edited 2009-09-20 22:01:35 by localhost)