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]
