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'" <users@tapestry.apache.org> 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'" <users@tapestry.apache.org> > 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'" <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] >> >> > > > --------------------------------------------------------------------- > 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
