RE: Database Connection in Logic Beans - pooling? => request cycle
The request cycle ends when the final view component (JSP) sends its output to the browser. Struts ends its involvement when your Action class returns an ActionForward object from its perform method. Struts forwards to the page defined in the ActionForward object and I don't think is involved after that point unless your page redirects back to a struts component. So, I would subclass the ActionServlet (the request starting point) and mark the time in the current session. Then I would mark the time at the end of my JSP to find out how long the request took to process. Dave >I got the message and I will use the sessionFacade pattern and use the >connection pool as you advised. >Nevertheless I would like to know where the request cycle ends in the >struts >framework? >I didn't find any diagram regarding the request cycle. >I would like to store (among other things) the time for processing each >request. >I suppose I'll have to put the code in the controller component, the >ActionServlet? >How can I best achieve this? > >Thanks to you all for your advice. >Frederic > >-Original Message- >From: David Graham [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, September 03, 2002 6:35 AM >To: [EMAIL PROTECTED] >Subject: RE: Database Connection in Logic Beans - pooling? > > >Do NOT save the request into the session. That's why there is a connection >pool (DataSource), you take one out, use it, and put it back. If you don't >return it you will ruin the whole point of the pool. The connection pool >idea was created to avoid the situation you described. You should always >ask the pool for a connection when you need one and put it back when >finished; your application's response time will greatly improve. > >Dave > > >Thanks to Troy, > > > >But I read a lot of Java literature and the struts archive over the past > >weeks but in the all the examples the connection is retrieved and >returned > >is the same class. I know it is the easiest and the best way to handle >the > >problem. > >In most cases it provides a solution. > >I would like to implement a more flexible solution: > >- Retrieving a connection and saving it in the context (request scope) or > >saving an id associated with the connection. > >- When a connection is needed in the request, look first in the context >if > >a > >connection has already been retrieved. > >- Based on a parameter => return the connection in the class. > >- Check at the end of the request if a connection exists, if yes return >it > >to the pool. > >=> Where does the request cycle ends? > >At the source I'm a database programmer so I prefer to manage the > >transactions myself. > >I think that another advantage of using a same connection through the >whole > >request is the fact that in case of heavy loading, when connections are > >difficult to obtain, the request can be served as a whole. I prefer X > >requests with 100% satisfaction and y not satisfied than x+y requests >with > >30% satisfaction. If you understand what I mean? > > > >Your help or advice will be appreciated. > >Frederic > > > >I've excluded EJB for my project because most of the data is read only or > >linked to one user only. > > > >-Original Message- > >From: Troy Hart [mailto:[EMAIL PROTECTED]] > >Sent: Monday, September 02, 2002 9:17 PM > >To: Struts Users Mailing List > >Subject: RE: Database Connection in Logic Beans - pooling? > > > > > >You can solve this problem by providing a business service framework for > >your application (There has been a lot of talk about this sort of thing > >on this list...I can't think of a particular thread to reference for you > >so you may just want to go through the archives). My approach to this > >problem has been to create a set of very coarse grained business service > >components (ours is an ecommerce system so we have components like the > >following: one for cataloging, one for requisitioning, one for order > >services, and etc...), where each component provides a public API that > >mirrors the "use-cases" one-to-one (for the most part). I think you will > >find that the top level "use-cases" defined for your system provide > >natural scoping boundaries for your transactions, and resource > >management in general. > > > >This approach will leave you with a set of re-usable business components > >that are not tied to struts and/or the servlet paradigm. Also, this API > >provides an abstraction that will allow you to hide complexity from your > >struts actions (or whatever else uses the API). For example, the > >component you expose could be a facade to an EJB Session bean > >(http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.htm >l > >). > > > >Anyway, my suggestion is to think about your problem a little > >differently. Sorry if I didn't provide enough details, my intention was > >simply to give a high level overview of how I see the problem and the > >solution. Once again, I would urge to lookup other threads on this topi
RE: Database Connection in Logic Beans - pooling? => request cycle
I got the message and I will use the sessionFacade pattern and use the connection pool as you advised. Nevertheless I would like to know where the request cycle ends in the struts framework? I didn't find any diagram regarding the request cycle. I would like to store (among other things) the time for processing each request. I suppose I'll have to put the code in the controller component, the ActionServlet? How can I best achieve this? Thanks to you all for your advice. Frederic -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 03, 2002 6:35 AM To: [EMAIL PROTECTED] Subject: RE: Database Connection in Logic Beans - pooling? Do NOT save the request into the session. That's why there is a connection pool (DataSource), you take one out, use it, and put it back. If you don't return it you will ruin the whole point of the pool. The connection pool idea was created to avoid the situation you described. You should always ask the pool for a connection when you need one and put it back when finished; your application's response time will greatly improve. Dave >Thanks to Troy, > >But I read a lot of Java literature and the struts archive over the past >weeks but in the all the examples the connection is retrieved and returned >is the same class. I know it is the easiest and the best way to handle the >problem. >In most cases it provides a solution. >I would like to implement a more flexible solution: >- Retrieving a connection and saving it in the context (request scope) or >saving an id associated with the connection. >- When a connection is needed in the request, look first in the context if >a >connection has already been retrieved. >- Based on a parameter => return the connection in the class. >- Check at the end of the request if a connection exists, if yes return it >to the pool. >=> Where does the request cycle ends? >At the source I'm a database programmer so I prefer to manage the >transactions myself. >I think that another advantage of using a same connection through the whole >request is the fact that in case of heavy loading, when connections are >difficult to obtain, the request can be served as a whole. I prefer X >requests with 100% satisfaction and y not satisfied than x+y requests with >30% satisfaction. If you understand what I mean? > >Your help or advice will be appreciated. >Frederic > >I've excluded EJB for my project because most of the data is read only or >linked to one user only. > >-Original Message- >From: Troy Hart [mailto:[EMAIL PROTECTED]] >Sent: Monday, September 02, 2002 9:17 PM >To: Struts Users Mailing List >Subject: RE: Database Connection in Logic Beans - pooling? > > >You can solve this problem by providing a business service framework for >your application (There has been a lot of talk about this sort of thing >on this list...I can't think of a particular thread to reference for you >so you may just want to go through the archives). My approach to this >problem has been to create a set of very coarse grained business service >components (ours is an ecommerce system so we have components like the >following: one for cataloging, one for requisitioning, one for order >services, and etc...), where each component provides a public API that >mirrors the "use-cases" one-to-one (for the most part). I think you will >find that the top level "use-cases" defined for your system provide >natural scoping boundaries for your transactions, and resource >management in general. > >This approach will leave you with a set of re-usable business components >that are not tied to struts and/or the servlet paradigm. Also, this API >provides an abstraction that will allow you to hide complexity from your >struts actions (or whatever else uses the API). For example, the >component you expose could be a facade to an EJB Session bean >(http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.htm l >). > >Anyway, my suggestion is to think about your problem a little >differently. Sorry if I didn't provide enough details, my intention was >simply to give a high level overview of how I see the problem and the >solution. Once again, I would urge to lookup other threads on this topic >to read what other people have said. > >Hope this helps, > >Troy > > >On Mon, 2002-09-02 at 10:45, Frederic Laub wrote: > > Hi, > > > > How do achieve the following: > > In some cases I want to get a connection at the beginning of a request > > (request scope), pass the same connection to all the java beans that are > > called in the request and return the connection at the end of the >request. > > Where do I put the code to return the connection to the pool at the end >of > > the request and in case of an error be sure that the connection is >returned > > to the pool? > > A same connection is required when all DML statements throughout a >request > > are part of a same transaction. > > The commit (or rollback in case of an error) statement is issued
