With a session opened and closed in a ServletFilter+ThreadLocal pattern, i think so.
-----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 7 octobre 2003 19:53 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] UPDATED: hibernate/webwork2 best practices What happens if you're using another interceptor in a chain, and it throws an error that halts processing? Will your hibernate interceptor be able to close off any resources it opened? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anoop Ranganath Sent: Tuesday, October 07, 2003 8:57 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] UPDATED: hibernate/webwork2 best practices Well, I wrote this description of how I was doing things about three weeks ago. I mentioned that something didn't smell right about this technique. It wasn't necessarily wrong, it just seemed that there should be a better way. Well, I think I found it. It's very clean, provides excellent separation between persistence and logic, and makes actions even more POJOish. I set up interceptors for our domain objects. In the before() I open a hibernate session, load the appropriate objects, and put them on the action. in the after() I check if the action has any errors, and if it doesn't, I flush the session and then I close it. The beauty is that the actions only manipulate the objects. Since the hibernate session is open, the changes to the objects are automagically persisted when it is flushed without having to call saveOrUpdate(). Actions become very, very testable. Also, I put this interceptor in _after_ the component interceptor, so I can fairly easily grab any components I want to use off of the action. In this case, the HibernateSession and DAO. This is definitely a hack, cause ideally, the action shouldn't be aware of them at all, but it's a poor man's way of using IoC in the interceptors. So far this has proven to be an excellent way of doing this. There are a few caveats however. Exceptions getting thrown from interceptors disappear into oblivion. Right now, I just catch all exceptions in the intercept() method, and add them as action errors. The second caveat is every call to an action results in a database hit. I'm sure there are ways around this, but for our purposes Any comments? Anoop On Tuesday, September 16, 2003, at 11:31 PM, Anoop Ranganath wrote: > I just started using WebWork2 yesterday, and I'm sold. A new > techonology hasn't kept me smiling for so long thinking "this is > right" since I first started playing with Ruby. > > I'm writing a vanilla database backed webapp for my client, and I'm > trying to decide where I should put the persistence code within the > WW2 framework. Right now I've implemented the Thread Local Session > seen here ( http://hibernate.bluemars.net/42.html ). I created a DAO > which uses the Thread Local Session to retrieve and persist the > business objects. I've made the DAOs components on the session and > any actions that need them are enabled for the DAOs. > > The thing is this seems clunky to me. I've only been using the > framework for two days, but something about this approach doesn't feel > like I'm fully leveraging WW's capabilities. I can't quite get my > nose on the smell, but it's definitely there. > > Any ideas? I'm sure this is a problem that's been solved many times > over. > > Anoop > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
