Not if you set the maximum size of the pool to some reasonable number. -----Original Message----- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 1:18 PM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
I am using a connection pool. My problem is, if each one of those 9 components retrieve a connection from the pool for each page rendered, multiplied by the number of users, this could lead to a quick exhaustion of resources. On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: > > Yes, a connection pool does help a bit. I didn't see where they were > using > a pool before. So, you're right, if the connections are being pooled > properly, nothing will be opening/closing. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of > Matt Welch > Sent: Monday, July 17, 2006 1:08 PM > To: Tapestry users > Subject: Re: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > This seems to be much ado about nothing: > > 1) He likely won't be actually "opening" or "closing" 9 connections in a > request. I hope it's a safe assumption that a connection pool is being > used. > > > 2) Unless I'm mistaken about Tapestry's architecture, these 9 separate > components won't be processed simultaneously within the context of a > single > request. All of the actions within that request will occur within the > thread > allocated by the servlet container to handle that request so your 9 > different data requests will happen one after the other and and no more > than > one connection will be used by that request at any one time. > > I suppose that under special circumstances you might need to be worried > about this. Let's say, perhaps, that these 9 components made repeated > simultaneous AJAX-style requests. In such a situation you might begin to > have an issue with strained connection pools. > > Matt > > > > On 7/17/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > > > If I make my components wait, won't I be stalling the creation of the > > page? > > Under heavy loads, how feasible will that be? > > > > On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > Oh, if you're worried about simultaneous connections to the database, > > you > > > don't have to worry. You can set the maximum size of your pool to > some > > > reasonable number. Then, have your components wait until a connection > > is > > > available in the pool. > > > > > > -----Original Message----- > > > From: Rui Pacheco [mailto:[EMAIL PROTECTED] > > > Sent: Monday, July 17, 2006 12:05 PM > > > To: Tapestry users > > > Subject: Re: A bit OT: how to manage database connections for multiple > > > components rendered simultaneously. > > > > > > I have several components. Each will retrieve one connection from the > > > pool, > > > do its thing and return it. > > > > > > If they are done one at the time, then its great for me. But if each > > user > > > that calls the page causes 9 simultaneous connections to open, I'll > need > > > to > > > revise my strategy. > > > > > > On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > > > Unless all components ask for their own connection, which I think is > > > what > > > > they were saying. > > > > > > > > -----Original Message----- > > > > From: kranga [mailto:[EMAIL PROTECTED] > > > > Sent: Monday, July 17, 2006 11:28 AM > > > > To: Tapestry users > > > > Subject: Re: A bit OT: how to manage database connections for > multiple > > > > components rendered simultaneously. > > > > > > > > Unless I'm missing something, you will not be using 9 connections as > > the > > > > components will render in serial order. So you will make 9 requests > > over > > > a > > > > single connection. > > > > > > > > ----- Original Message ----- > > > > From: "James Carman" <[EMAIL PROTECTED]> > > > > To: "'Tapestry users'" <users@tapestry.apache.org>; "'Tapestry > users'" > > > > <tapestry-user@jakarta.apache.org> > > > > Sent: Monday, July 17, 2006 10:19 AM > > > > Subject: RE: A bit OT: how to manage database connections for > multiple > > > > components rendered simultaneously. > > > > > > > > > > > > > All code within one request can easily just use one > > > connection. That's > > > > > what > > > > > we do with Tapernate. > > > > > > > > > > -----Original Message----- > > > > > From: Rui Pacheco [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, July 17, 2006 10:13 AM > > > > > To: Tapestry users; Tapestry users > > > > > Subject: A bit OT: how to manage database connections for multiple > > > > > components rendered simultaneously. > > > > > > > > > > Hi all > > > > > > > > > > This is not a pure Tapestry question, but I believe you have seen > > this > > > > > before and might be able to give me some guiding light. > > > > > > > > > > I have a web application, which I am splitting into several > > fragments, > > > > ie, > > > > > components, each one rendering content stored in a database. I > just > > > > > realised > > > > > my index page would have 9 such fragments and if each is to > retrieve > > a > > > > > connection from the pool to get its content, the stress on the db > > > server > > > > > might be crazy, even if each request is quite short. > > > > > > > > > > I have a connection pool, but even with that I don't believe its > > > healthy > > > > > to > > > > > use 9 connections at the same time. What about the other users? > > > > > > > > > > How would you deal with this issue? > > > > > -- > > > > > Cumprimentos, > > > > > Rui Pacheco > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Cumprimentos, > > > Rui Pacheco > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Cumprimentos, > > Rui Pacheco > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cumprimentos, Rui Pacheco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]