[Jakarta HiveMind Wiki] Updated: HibernateSupport

[hi...@jakarta.apache.org]

   Date: 2004-10-05T07:01:22
   Editor: JeanFrancoisPoilpret <jf...@yahoo.fr>
   Wiki: Jakarta HiveMind Wiki
   Page: HibernateSupport
   URL: http://wiki.apache.org/jakarta-hivemind/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: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org