hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hensley, Richard" <>
Subject RE: Hibernate (HIVEMIND-54)
Date Wed, 08 Dec 2004 20:15:04 GMT

Yes, I think invalidating the session in the convert method works fine. 

Here is some more feedback on HibernateSessionWrapper. 

I'm not a real big fan of stripping off checked exceptions on tools that
deal with things outside the running instance of a JVM. Stripping the
checked exceptions allows programmers to become disinterested in exceptional
cases that occur so often when dealing with tools that are heavily
influenced by the environment outside of the java application. In this case,
a database definitely qualifies as something that I consider unreliable and
requires extra attention when dealing with it from your java application.

However, on the other hand, I like extra methods that you have added to the
wrapper that makes hibernate more convenient to use.

Transaction management comments. 

There are two ways of looking at transaction management. There is the EJB
world, where a lot of things are part of the transaction, i.e. JDBC, JMS,
and JCA connections, and there is the simple JDBC only world. The
applications that I build generally live in the JDBC world and require
simple transaction management. I would be inclined to use a knock off of the
HibernateUtils class that is documented in Hibernate in Action, and is part
of the CaveatEmptor sample application. That utility class is basically a
ThreadLocalStorage thing that stores a single session, and a single
transaction. This, by the way, is basically what you implemented with
HibernateSessionWrapper and the TransactionFilter. By the way, as you know
hibernate plays nicely in both worlds.

When your application is in the complex world of multiple transactional
entities, I can see how declarative transactional demarcation would be used.

Another thing you might want to consider is that some hibernate users
suggest that reads from the database occur under transaction control so that
database isolation can be used. This is another argument in favor of
transaction and open session in view. Of course you can read many arguments
on this topic on the hibernate website and forum. I think it comes down to
the balance between ivory tower purity, and solid practical application

>From my point of view, a reasonable hibernate integration needs to provide
for three areas of concern.

SessionFactory configuration (this needs some work, the hivetranse does a
pretty good job of this)
Session acquisition (you've done this)
Hibernate Transactional Control (I think this could be simpler, possibly by
combining simple transactional control with the session)

I also think that a transactional service is a completely separate concern
from a hibernate integration. I think that a transactional service could use
a hibernate integration, but the hibernate integration needs to be useful as
a tool.


-----Original Message-----
From: James Carman [] 
Sent: Tuesday, December 07, 2004 7:00 PM
Subject: RE: Hibernate (HIVEMIND-54)

Well, the article never did get completed.  I played around with the example
code and came up with what 

No, the article has not been finished yet.  I ran into a "busy season" and
haven't been able to catch up enough to get the article completed.  

Session Management:

Yes, the code does use the OpenSessionInView pattern (although I have not
read the book).  Yes, the HibernateSessionWrapper service does use the
threaded model and the session is discarded whenever the request is
completed.  Your point about me not discarding the session immediately is a
good one, so I think I'll change my code.  What do you think about adding
some logic to the convert() method which clears the session variable
whenever it converts a HibernateException?  Then, in the getSession()
method, I could do something like this...

public Session getSession()
  if( session == null )
  throw new RuntimeException( "Attempting to use a Hibernate session after a
HibernateException has been thrown." );
  return session;

Do you think that will work?

Transaction Management:

Yes, I use both of these patterns in my code.  I wrote my transaction
interceptor first.  It performs the transaction boundary logic, like you
would think.  But, it also does a bit more.  You can pass it a list of
"rollbackOnlyExceptions" when you construct it (via BuilderFactory of
course).  If any of the methods throw one of those types of exception
(intended for the caught exception types, as it automatically rolls back
when any runtime exception is thrown), it will tell the transaction service
to setRollbackOnly().  I intended to use this interceptor only for my
transaction management.  But, then I thought "what if an action wishes to
call two different methods under the same transaction?"  Then I would have
to start adding methods to my services (a la SessionFacade) which call those
two methods internally.  So, I decided to go with the servlet filter, which
sets up the transaction boundaries ONLY and has no notion of
"rollbackOnlyExceptions."  I guess I could have (and probably will now) gone
back and factored out the "rollback only logic" out of the transaction
interceptor and create another RollbackOnlyInterceptor.  Is that enough
light? :-)  

Thanks for taking a look at that stuff and giving me some feedback.  I have
put a lot of work into that code, because I wanted it to be a good
"real-world" example of how to use HiveMind in a web application.  I will
make these changes before I finish the article (if TSS will still let me
write it this late).  

-----Original Message-----
From: Hensley, Richard [] 
Sent: Tuesday, December 07, 2004 9:06 PM
Subject: Hibernate (HIVEMIND-54)

There is a note from James Carman that the contains
some interesting stuff, and that there is an article being written for TSS.

James, did the article get completed. I was searching around on TSS, but
could not find it.

If not, I have a few questions about your example code.

Session Management Comments:

>>From what I was able to piece together, the hibernate session is managed
using the OpenSessionInView pattern that is present throughout the Hibernate
in Action book. The one in the book uses thread local storage, but it's the
same idea. Is this basically right?

Added to this is that the session is automatically closed when a thread is
through using the thread. I make this comment based on the threaded model of
the HibernateSessionWrapper service.

The one thing I did notice about the HibernateSessionWrapper is that it does
not discard the session object when an exception occurs. It is a documented
hibernate practice to discard the session because it is invalid when an
exception occurs.

Transaction Management Comments:

>>From what I could gather there are two choices.

1. Use the Transaction servlet filter that starts a transaction at the start
of each request, and ends it after the request has been completed.

2. Use the Transaction Interceptor on targeted services. This allows certain
methods to create transactional boundaries based on their entry and exit.

I'm not a Struts expert, so I'm not sure if these two methods were intended
to be used together or not. Could you shed some light?


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

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

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

View raw message