Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
1) To have 9 pages rendering simultaneously you need to have very very high traffic. 2) We have systems with 500 connections to the database running just fine. It is easier to throw hardware on a well-known problem (at least to some extent) than to spend cycles over-engineering. 3) Think of caching the data if possible or think of implementing an aggregator that can send a single request on behalf of all components and distribute the results to them. - Original Message - From: "Rui Pacheco" <[EMAIL PROTECTED]> To: "Tapestry users" Sent: Tuesday, July 18, 2006 6:30 PM Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Still, if the components were all rendered at the same time, you would be tying up 9 connections simultaneously, and that would kill your response times. On 7/18/06, kranga <[EMAIL PROTECTED]> wrote: Yes I would be fine with opening/closing 9 connections to the database if they are from a connection pool because then I would be opening/closing 0 connections in reality! - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 12:48 PM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. > So, you'd be okay with opening/closing 9 connections to the database > during > each request cycle? I'd think it would be better to just use one > during > the > entire request cycle. > > -Original Message- > From: kranga [mailto:[EMAIL PROTECTED] > Sent: Monday, July 17, 2006 12:40 PM > To: Tapestry users > Subject: Re: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > Even if all components ask for their own connection, assuming > components > release connections when they are done, you would still expect only 1 > connection in use (though it may physically travel on upto 8 different > connection, there is only 1 connection open at any given time). > > A much better optimization would be to add an observer/mediator style > pattern - a "data provider" that each component is able to tell what data > it > > needs (perhaps in the renderComponent method) and when the first > request > for > > the data is made, the provider creates a SQL encompassing all requests, > gets > > it and is able to dish it out. However, I personally (without any more > info) > > would classify this optimization as pre-mature. 8 requests to the database > may only result in about 400ms while I have a monster elsewhere slowing > everything down. Plus you need to take into account how often the index > page > > is actually invoked. > > - Original Message - > From: "James Carman" <[EMAIL PROTECTED]> > To: "'Tapestry users'" > Sent: Monday, July 17, 2006 11:36 AM > Subject: RE: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > >> 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'" ; "'Tapestry users'" >> >> 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. >>
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Still, if the components were all rendered at the same time, you would be tying up 9 connections simultaneously, and that would kill your response times. On 7/18/06, kranga <[EMAIL PROTECTED]> wrote: Yes I would be fine with opening/closing 9 connections to the database if they are from a connection pool because then I would be opening/closing 0 connections in reality! - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 12:48 PM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. > So, you'd be okay with opening/closing 9 connections to the database > during > each request cycle? I'd think it would be better to just use one during > the > entire request cycle. > > -Original Message- > From: kranga [mailto:[EMAIL PROTECTED] > Sent: Monday, July 17, 2006 12:40 PM > To: Tapestry users > Subject: Re: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > Even if all components ask for their own connection, assuming components > release connections when they are done, you would still expect only 1 > connection in use (though it may physically travel on upto 8 different > connection, there is only 1 connection open at any given time). > > A much better optimization would be to add an observer/mediator style > pattern - a "data provider" that each component is able to tell what data > it > > needs (perhaps in the renderComponent method) and when the first request > for > > the data is made, the provider creates a SQL encompassing all requests, > gets > > it and is able to dish it out. However, I personally (without any more > info) > > would classify this optimization as pre-mature. 8 requests to the database > may only result in about 400ms while I have a monster elsewhere slowing > everything down. Plus you need to take into account how often the index > page > > is actually invoked. > > - Original Message - > From: "James Carman" <[EMAIL PROTECTED]> > To: "'Tapestry users'" > Sent: Monday, July 17, 2006 11:36 AM > Subject: RE: A bit OT: how to manage database connections for multiple > components rendered simultaneously. > > >> 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'" ; "'Tapestry users'" >> >> 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
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Yes I would be fine with opening/closing 9 connections to the database if they are from a connection pool because then I would be opening/closing 0 connections in reality! - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 12:48 PM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. So, you'd be okay with opening/closing 9 connections to the database during each request cycle? I'd think it would be better to just use one during the entire request cycle. -Original Message- From: kranga [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 12:40 PM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Even if all components ask for their own connection, assuming components release connections when they are done, you would still expect only 1 connection in use (though it may physically travel on upto 8 different connection, there is only 1 connection open at any given time). A much better optimization would be to add an observer/mediator style pattern - a "data provider" that each component is able to tell what data it needs (perhaps in the renderComponent method) and when the first request for the data is made, the provider creates a SQL encompassing all requests, gets it and is able to dish it out. However, I personally (without any more info) would classify this optimization as pre-mature. 8 requests to the database may only result in about 400ms while I have a monster elsewhere slowing everything down. Plus you need to take into account how often the index page is actually invoked. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 11:36 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. 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'" ; "'Tapestry users'" 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] - 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]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Rui Pacheco wrote: 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? Each request will be served in separate thread, so all your 9 components will be rendered one-by-one and one connection associated with current thread will be used by all of them. Thats off course if you have your connection implemented as threaded Hivemind service. By the way, I would highly recommended you to implement your logic as Hivemind services too, and wire those services with connection. In other words, use DAO pattern. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Rui., What you're worrying about is a non-issue. Components are rendered serially (one after another), thus the connection will be reused. You should use a connection pool of course (C3p0 recommended). Thus you can take it from the pool, return it back from one component, and it will be picked by another component soon after. Alex Rui Pacheco wrote: 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'" ; "'Tapestry users'" > > > > > > 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 > > > &g
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
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'" ; "'Tapestry > users'" > > > > > > > > Sent: Monday, July 17, 2006 10:19 AM > > > > Subject: RE: A bit OT: how to manage database connections for > multiple > > > > component
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'" ; "'Tapestry users'" > > > > > > 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 > > > &g
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
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'" ; "'Tapestry users'" > > > > > > 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, > > > > comp
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'" ; "'Tapestry users'" > > > > 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
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Well, what you do is tell your pool to wait until one comes back into the pool. So, you set your maximum pool size to something like 200 (if your db can handle more, do more if needed) connections. That, along with using only one connection per request cycle should help out. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 12:50 PM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. 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'" ; "'Tapestry users'" > > > > 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]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
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'" ; "'Tapestry users'" > > 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
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
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'" ; "'Tapestry users'" > > 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]
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
So, you'd be okay with opening/closing 9 connections to the database during each request cycle? I'd think it would be better to just use one during the entire request cycle. -Original Message- From: kranga [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 12:40 PM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Even if all components ask for their own connection, assuming components release connections when they are done, you would still expect only 1 connection in use (though it may physically travel on upto 8 different connection, there is only 1 connection open at any given time). A much better optimization would be to add an observer/mediator style pattern - a "data provider" that each component is able to tell what data it needs (perhaps in the renderComponent method) and when the first request for the data is made, the provider creates a SQL encompassing all requests, gets it and is able to dish it out. However, I personally (without any more info) would classify this optimization as pre-mature. 8 requests to the database may only result in about 400ms while I have a monster elsewhere slowing everything down. Plus you need to take into account how often the index page is actually invoked. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 11:36 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. > 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'" ; "'Tapestry users'" > > 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] > > - 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: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Even if all components ask for their own connection, assuming components release connections when they are done, you would still expect only 1 connection in use (though it may physically travel on upto 8 different connection, there is only 1 connection open at any given time). A much better optimization would be to add an observer/mediator style pattern - a "data provider" that each component is able to tell what data it needs (perhaps in the renderComponent method) and when the first request for the data is made, the provider creates a SQL encompassing all requests, gets it and is able to dish it out. However, I personally (without any more info) would classify this optimization as pre-mature. 8 requests to the database may only result in about 400ms while I have a monster elsewhere slowing everything down. Plus you need to take into account how often the index page is actually invoked. - Original Message - From: "James Carman" <[EMAIL PROTECTED]> To: "'Tapestry users'" Sent: Monday, July 17, 2006 11:36 AM Subject: RE: A bit OT: how to manage database connections for multiple components rendered simultaneously. 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'" ; "'Tapestry users'" 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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'" ; "'Tapestry users'" 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
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
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'" ; "'Tapestry users'" 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]
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'" ; "'Tapestry users'" 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]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Many thanks! On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: Use a threadlocal variable to hold the connection for the current request. Set the value from your pool using a WebRequestServicerFilter and make sure you clean it up at the end of the request. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 10:32 AM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Hmmm. I am not using Hibernate, the learning curve is too steep for this project. Can you sugest a way to solve this with handwritten code? On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: > > 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] > > -- Cumprimentos, Rui Pacheco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cumprimentos, Rui Pacheco
RE: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Use a threadlocal variable to hold the connection for the current request. Set the value from your pool using a WebRequestServicerFilter and make sure you clean it up at the end of the request. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 10:32 AM To: Tapestry users Subject: Re: A bit OT: how to manage database connections for multiple components rendered simultaneously. Hmmm. I am not using Hibernate, the learning curve is too steep for this project. Can you sugest a way to solve this with handwritten code? On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: > > 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] > > -- Cumprimentos, Rui Pacheco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit OT: how to manage database connections for multiple components rendered simultaneously.
Hmmm. I am not using Hibernate, the learning curve is too steep for this project. Can you sugest a way to solve this with handwritten code? On 7/17/06, James Carman <[EMAIL PROTECTED]> wrote: 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] -- Cumprimentos, Rui Pacheco
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]
