Hmm. I think the answer here is one of resource starvation - the
resource in this case being the CPU. It seems that core of your test is
'Select * from table1'
Where is the database? Is it another application on the same box? What
mechanism do you use to connect between the database and the a
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Daad,
>
> [EMAIL PROTECTED] wrote:
> | No, my test is done with threads that connect using sockets. Server
> | listen with ServerSocket and 30 Threads are started connecting to it.
>
> Er... did you write your own server, or are you using Tomcat
> I haven't looked at the source, but I'm willing to bet there is at least
> one sync block -- the pooling implementation would have to perform a
> brief sync when it borrows a connection object from the pool. In
> addition, if this is from a fresh startup of tomcat without a minIdle
> setting (de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daad,
[EMAIL PROTECTED] wrote:
| No, my test is done with threads that connect using sockets. Server
| listen with ServerSocket and 30 Threads are started connecting to it.
Er... did you write your own server, or are you using Tomcat?
I'm sorry...
I haven't looked at the source, but I'm willing to bet there is at least
one sync block -- the pooling implementation would have to perform a
brief sync when it borrows a connection object from the pool. In
addition, if this is from a fresh startup of tomcat without a minIdle
setting (default=
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Daad,
>
> [EMAIL PROTECTED] wrote:
> | i think i don't get the utility of a connection pooling, since i have
> this situation: 30 threads try to perform at same time a db access with
> the call:
> |
> | new Database().doSomething()
>
> Are you s
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Daad,
>
> [EMAIL PROTECTED] wrote:
> | I missed some messages seems.. So is the enqueuing thing a bad
> | behaviour of pooling or is it just normal?
>
> I suspect you have a problem with your code, somewhere. Are you creating
> a new Database ob
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Subject: RE: Connection pooling again
> >
> > what should i ask to check to the db admin?
>
> Start with: does the db limit the number of connections from a given
> client (which in this case, is the box T
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Subject: RE: Connection pooling again
>
> what should i ask to check to the db admin?
Start with: does the db limit the number of connections from a given
client (which in this case, is the box Tomcat is running on)?
> Ho
> Your queueing problem most likely has nothing to do with the pooling
> capability but rather with your app, your database, or your test driver.
>
> 1) If the test driver is browser based (e.g., Java script), you're
> limited to two connections to a given server. If your test driver is
> using so
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Subject: Re: Connection pooling again
>
> So is the enqueuing thing a bad behaviour of pooling or is it
> just normal?
Your queueing problem most likely has nothing to do with the pooling
capability but rather with your app
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daad,
[EMAIL PROTECTED] wrote:
| I missed some messages seems.. So is the enqueuing thing a bad
| behaviour of pooling or is it just normal?
I suspect you have a problem with your code, somewhere. Are you creating
a new Database object every time? D
want to partecipate... thanks
-- Initial Header ---
>From : "Christopher Schultz" [EMAIL PROTECTED]
To : "Tomcat Users List" users@tomcat.apache.org
Cc :
Date : Wed, 09 Apr 2008 10:58:58 -0400
Subject : Re: Connection pooling agai
Christopher Schultz wrote:
Mikolaj Rydzewski wrote:
| You should get DataSource object from JNDI
| first, and then pass it to other threads. Every thread should just call
| DataSource.getConnection().
That's a bad idea. The reason you store the DataSource in JNDI is so
that it is universally ava
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mikolaj,
Mikolaj Rydzewski wrote:
| JNDI lookups are expensive.
No, they're not. We're not talking about using a remote JNDI server or
AD or anything like that. This is all local and the lookups are very fast.
To convince yourself, run this simple
[EMAIL PROTECTED] wrote:
i think i don't get the utility of a connection pooling, since i have this
situation: 30 threads try to perform at same time a db access with the call:
new Database().doSomething()
JNDI lookups are expensive. You should get DataSource object from JNDI
first, and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daad,
[EMAIL PROTECTED] wrote:
| i think i don't get the utility of a connection pooling, since i have
this situation: 30 threads try to perform at same time a db access with
the call:
|
| new Database().doSomething()
Are you sure you're using your
because i do from same ip (mine)?
-- Initial Header ---
>From : "Caldarale, Charles R" [EMAIL PROTECTED]
To : "Tomcat Users List" users@tomcat.apache.org
Cc :
Date : Wed, 9 Apr 2008 06:18:40 -0500
Subject : RE: Connection pooling
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Subject: Connection pooling again
>
> i think i don't get the utility of a connection pooling,
> since i have this situation: 30 threads try to perform at
> same time a db access with the call:
Are you running the 30
i think i don't get the utility of a connection pooling, since i have this
situation: 30 threads try to perform at same time a db access with the call:
new Database().doSomething()
My Database class is done like that:
public class Database {
private long start = 0;
private C
20 matches
Mail list logo
