Re: Hibernate and Struts Usage Pattern question/survey
On Tue, 1 Mar 2005 17:48:40 -0500, Joe Hertz <[EMAIL PROTECTED]> wrote: > That is, usually you want the request to begin a transaction early > and either commit or rollback at the end. Hmm... I was under the impression that you **always** want to begin your transaction as late as possible, not early. Sticking something within a transactional context slows things down as some resources are locked and can't be shared. > But SOMETHING has to know when to begin a database transaction and decide to > roll it back or not. The business objects won't necessarily. Well, if you implement something like a Session Facade, that's where you will know to group several actions into a transaction. > Since Struts knows when that request begins and ends, I use it to handle it. > I have it talk to my persistence layer (not necessarily Hibernate. I didn't > couple myself to it here, there's an encapsulation going on) to do > initialization and cleanup in a request processor. I really don't know much about Hibernate yet, but as Chris already said: "Hibernate is for persistence and should stay in your persistence layer. Seems wrong that ANY part of Struts should know about Hibernate at all. NG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate and Struts Usage Pattern question/survey
This particular application (tiny, not used much, never will be, and was written in a hurry and not by me) implementing it after the fact ain't going to happen. Not worth the cost to the customer. In general though, youre quite correct (and I'm cutting through the layers of abstraction. Ultimately Actions do result in things happening. Your C refers to the M at some point. I have no doubts I should be more anal on this subject though, so maybe I should ask this question. To me a WebApp request typically has a nice predefined unit of work for the database. That is, usually you want the request to begin a transaction early and either commit or rollback at the end. But SOMETHING has to know when to begin a database transaction and decide to roll it back or not. The business objects won't necessarily. Your first method call may need to be rolled back after the fact and it can't know what happens later... So where's the best place to manage that? (I suspect an obvious and better answer than mine will be given to me en masse after I hit send) Since Struts knows when that request begins and ends, I use it to handle it. I have it talk to my persistence layer (not necessarily Hibernate. I didn't couple myself to it here, there's an encapsulation going on) to do initialization and cleanup in a request processor. Sounds like you prefer option 2. If it's stashed in a ThreadLocal with a static Accessor. It never winds up in the web tier at all, even if generated in the Request Processor. The actions NEVER see it at all... > Just before I go to bed after a long work day: what the heck has > Hibernate or any other Resource Tier means to do with the > presentation layer (Struts)? Hibernate is just for Persistence, > with the details usually isolated from the web tier by (usually > several) additional layers (DAO, Services, Business Delegate > and so on). Hibernate lives in the backend, business logic > comes somewhere on top of that, and the web tier (and Struts > is part of and limited to that) is for presentation purposes > only. If you start to care about Hibernate Sessions in the web > part, you should possibly rethink your architecture. > > -- Chris. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate and Struts Usage Pattern question/survey
This particular application (tiny, not used much, never will be, and was written in a hurry and not by me) implementing it after the fact ain't going to happen. Not worth the cost to the customer. In general though, youre quite correct (and I'm cutting through the layers of abstraction. Ultimately Actions do result in things happening. Your C refers to the M at some point. I have no doubts I should be more anal on this subject though, so maybe I should ask this question. To me a WebApp request typically has a nice predefined unit of work for the database. That is, usually you want the request to begin a transaction early and either commit or rollback at the end. But SOMETHING has to know when to begin a database transaction and decide to roll it back or not. The business objects won't necessarily. Your first method call may need to be rolled back after the fact and it can't know what happens later... So where's the best place to manage that? (I suspect an obvious and better answer than mine will be given to me en masse after I hit send) Since Struts knows when that request begins and ends, I use it to handle it. I have it talk to my persistence layer (not necessarily Hibernate. I didn't couple myself to it here, there's an encapsulation going on) to do initialization and cleanup in a request processor. Sounds like you prefer option 2. If it's stashed in a ThreadLocal with a static Accessor. It never winds up in the web tier at all, even if generated in the Request Processor. The actions NEVER see it at all... > Just before I go to bed after a long work day: what the heck has > Hibernate or any other Resource Tier means to do with the > presentation layer (Struts)? Hibernate is just for Persistence, > with the details usually isolated from the web tier by (usually > several) additional layers (DAO, Services, Business Delegate > and so on). Hibernate lives in the backend, business logic > comes somewhere on top of that, and the web tier (and Struts > is part of and limited to that) is for presentation purposes > only. If you start to care about Hibernate Sessions in the web > part, you should possibly rethink your architecture. > > -- Chris. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate and Struts Usage Pattern question/survey
Joe Hertz wrote: I've been hearing this from the Spring set. I'm waiting for a good book to come out on it. www.springlive.com a REALLY good book for more than just spring. It's 30 bucks online, money WELL spent. Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate and Struts Usage Pattern question/survey
On Tuesday 01 March 2005 22:07, Joe Hertz wrote: > Curious as to which concept Struts/Hibernate implementers like more > for implementation: > > #1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate > Session object into the httpServletRequest. Every action has a fresh > Hibernate Session raring to go if it needs it. Then again it has it > even if it doesn't but the Hibernate folks swear that this is > basically no work for the application. As if the guts of the Session > object don't really exist until it's first method call. > > #2- Hibernate's Struts plugin concept: Getting Hibernate Sessions > explicitly in action methods, but stashing them in a ThreadLocal to > not get any you don't need. If you try to get it again in the same > thread, you get the one you already had. > > I guess the implies solution here is "Rely on the thread destroy() > method to kill the Session when it aint needed no more > > #3- something else > > Since Hibernate also suggests an approach similar to #1 via a Servlet > filter anyway, I opt to do it via a Request Processor subclass. > > I'm curious how other people go about it. Anyone ever encounter a > reason they had to switch? > > -Joe Just before I go to bed after a long work day: what the heck has Hibernate or any other Resource Tier means to do with the presentation layer (Struts)? Hibernate is just for Persistence, with the details usually isolated from the web tier by (usually several) additional layers (DAO, Services, Business Delegate and so on). Hibernate lives in the backend, business logic comes somewhere on top of that, and the web tier (and Struts is part of and limited to that) is for presentation purposes only. If you start to care about Hibernate Sessions in the web part, you should possibly rethink your architecture. -- Chris. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate and Struts Usage Pattern question/survey
I've been hearing this from the Spring set. I'm waiting for a good book to come out on it. The only reason I asked is an application I was maintaining (it had been written using method #2) had some Session/Transaction handling bugs exposed when migrated it to Hibernate 3. So I decided to refactor it to the way I usually do handle the issue (not as a fix per se, just so I could understand what was happening more easily -- thread debugging...ewww) and, lo, it solved the problem. I'm probably going to deploy it like this since its usage makes it no way likely to encounter a scaling issue, but it got me wondering about where the bathwater began and where the baby ended. -Original Message- From: Brandon Mercer [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 4:48 PM To: Struts Users Mailing List Subject: Re: Hibernate and Struts Usage Pattern question/survey Joe Hertz wrote: >Curious as to which concept Struts/Hibernate implementers like more for >implementation: > >#1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate >Session object into the httpServletRequest. Every action has a fresh >Hibernate Session raring to go if it needs it. Then again it has it even if >it doesn't but the Hibernate folks swear that this is basically no work for >the application. As if the guts of the Session object don't really exist >until it's first method call. > >#2- Hibernate's Struts plugin concept: Getting Hibernate Sessions explicitly >in action methods, but stashing them in a ThreadLocal to not get any you >don't need. If you try to get it again in the same thread, you get the one >you already had. > >I guess the implies solution here is "Rely on the thread destroy() method to >kill the Session when it aint needed no more > >#3- something else > >Since Hibernate also suggests an approach similar to #1 via a Servlet filter >anyway, I opt to do it via a Request Processor subclass. > >I'm curious how other people go about it. Anyone ever encounter a reason >they had to switch? > > Joe, I currently use struts+spring+hibernate. The addition of spring helps quite a bit and gives you a very clean layout. If done correctly you can switch persistance layers without any trouble. Check out http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse. It's a nifty toolkit that shows you how to do this very easily. Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hibernate and Struts Usage Pattern question/survey
I've been hearing this from the Spring set. I'm waiting for a good book to come out on it. The only reason I asked is an application I was maintaining (it had been written using method #2) had some Session/Transaction handling bugs exposed when migrated it to Hibernate 3. So I decided to refactor it to the way I usually do handle the issue (not as a fix per se, just so I could understand what was happening more easily -- thread debugging...ewww) and, lo, it solved the problem. I'm probably going to deploy it like this since its usage makes it no way likely to encounter a scaling issue, but it got me wondering about where the bathwater began and where the baby ended. -Original Message- From: Brandon Mercer [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 4:48 PM To: Struts Users Mailing List Subject: Re: Hibernate and Struts Usage Pattern question/survey Joe Hertz wrote: >Curious as to which concept Struts/Hibernate implementers like more for >implementation: > >#1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate >Session object into the httpServletRequest. Every action has a fresh >Hibernate Session raring to go if it needs it. Then again it has it even if >it doesn't but the Hibernate folks swear that this is basically no work for >the application. As if the guts of the Session object don't really exist >until it's first method call. > >#2- Hibernate's Struts plugin concept: Getting Hibernate Sessions explicitly >in action methods, but stashing them in a ThreadLocal to not get any you >don't need. If you try to get it again in the same thread, you get the one >you already had. > >I guess the implies solution here is "Rely on the thread destroy() method to >kill the Session when it aint needed no more > >#3- something else > >Since Hibernate also suggests an approach similar to #1 via a Servlet filter >anyway, I opt to do it via a Request Processor subclass. > >I'm curious how other people go about it. Anyone ever encounter a reason >they had to switch? > > Joe, I currently use struts+spring+hibernate. The addition of spring helps quite a bit and gives you a very clean layout. If done correctly you can switch persistance layers without any trouble. Check out http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse. It's a nifty toolkit that shows you how to do this very easily. Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hibernate and Struts Usage Pattern question/survey
Joe Hertz wrote: Curious as to which concept Struts/Hibernate implementers like more for implementation: #1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate Session object into the httpServletRequest. Every action has a fresh Hibernate Session raring to go if it needs it. Then again it has it even if it doesn't but the Hibernate folks swear that this is basically no work for the application. As if the guts of the Session object don't really exist until it's first method call. #2- Hibernate's Struts plugin concept: Getting Hibernate Sessions explicitly in action methods, but stashing them in a ThreadLocal to not get any you don't need. If you try to get it again in the same thread, you get the one you already had. I guess the implies solution here is "Rely on the thread destroy() method to kill the Session when it aint needed no more #3- something else Since Hibernate also suggests an approach similar to #1 via a Servlet filter anyway, I opt to do it via a Request Processor subclass. I'm curious how other people go about it. Anyone ever encounter a reason they had to switch? Joe, I currently use struts+spring+hibernate. The addition of spring helps quite a bit and gives you a very clean layout. If done correctly you can switch persistance layers without any trouble. Check out http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse. It's a nifty toolkit that shows you how to do this very easily. Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hibernate and Struts Usage Pattern question/survey
Curious as to which concept Struts/Hibernate implementers like more for implementation: #1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate Session object into the httpServletRequest. Every action has a fresh Hibernate Session raring to go if it needs it. Then again it has it even if it doesn't but the Hibernate folks swear that this is basically no work for the application. As if the guts of the Session object don't really exist until it's first method call. #2- Hibernate's Struts plugin concept: Getting Hibernate Sessions explicitly in action methods, but stashing them in a ThreadLocal to not get any you don't need. If you try to get it again in the same thread, you get the one you already had. I guess the implies solution here is "Rely on the thread destroy() method to kill the Session when it aint needed no more #3- something else Since Hibernate also suggests an approach similar to #1 via a Servlet filter anyway, I opt to do it via a Request Processor subclass. I'm curious how other people go about it. Anyone ever encounter a reason they had to switch? -Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hibernate and Struts Usage Pattern question/survey
Curious as to which concept Struts/Hibernate implementers like more for implementation: #1- Ted Husted's example of Struts and Hibernate. Stick the Hibernate Session object into the httpServletRequest. Every action has a fresh Hibernate Session raring to go if it needs it. Then again it has it even if it doesn't but the Hibernate folks swear that this is basically no work for the application. As if the guts of the Session object don't really exist until it's first method call. #2- Hibernate's Struts plugin concept: Getting Hibernate Sessions explicitly in action methods, but stashing them in a ThreadLocal to not get any you don't need. If you try to get it again in the same thread, you get the one you already had. I guess the implies solution here is "Rely on the thread destroy() method to kill the Session when it aint needed no more #3- something else Since Hibernate also suggests an approach similar to #1 via a Servlet filter anyway, I opt to do it via a Request Processor subclass. I'm curious how other people go about it. Anyone ever encounter a reason they had to switch? -Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
