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]
