hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Jakarta HiveMind Wiki] Updated: HibernateSupport
Date Tue, 05 Oct 2004 14:01:22 GMT
   Date: 2004-10-05T07:01:22
   Editor: JeanFrancoisPoilpret <>
   Wiki: Jakarta HiveMind Wiki
   Page: HibernateSupport

   no comment

Change Log:

@@ -80,3 +80,18 @@
 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.
+= 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message