Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sinoea,
sinoea kaabi wrote:
Christopher Schultz wrote:
You aren't using any class-level members in your static methods so
you should be fine.
This means that I cannot declare a:
public class Data {
private static DataSource datasource = null;
public static DataSource getDataSource() {
if (datasource == null) {
// create a datasource
}
return datasource;
}
}
Well, you /can/, but it wouldn't be a very good idea.
In the code above the class-level member is the datasource.
Do you mean I should do like this instead:
public class Data {
public static DataSource getDataSource() {
// create a new datasource for each call to this method
return datasource;
}
}
Assuming that the 'datasource' object is still shared among threads,
it's still a bad idea. DataSource objects are not guaranteed to be
threadsafe, so you shoule not share them.
This is a bad example, because you should never cache the DataSource in
the first place: you should always get it from the JNDI tree.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjXmj8ACgkQ9CaO5/Lv0PDlcgCdFNuTHa9TJL8zLKfKCTMWEn0+
n38AniRE9T74fDioAZeOuVI/HbZlYIf+
=rQsW
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johnny, Johnny Kewl wrote: If a datasource in DBCP represents the pool... you cant, you'd make a million data pools... No, the DataSource object does not represent the pool per se. It's just a factory that produces Connection objects (which, in turn, come from the pool). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjXmo8ACgkQ9CaO5/Lv0PADTACgte0ni15h+rcmslF7YI9EWhi4 jlIAn3ULPK3LRdxd6PAvCv8k/mT0zsF1 =P0sr -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: Christopher Schultz [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Monday, September 22, 2008 3:14 PM
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sinoea,
sinoea kaabi wrote:
Christopher Schultz wrote:
You aren't using any class-level members in your static methods so
you should be fine.
This means that I cannot declare a:
public class Data {
private static DataSource datasource = null;
public static DataSource getDataSource() {
if (datasource == null) {
// create a datasource
}
return datasource;
}
}
Well, you /can/, but it wouldn't be a very good idea.
In the code above the class-level member is the datasource.
Do you mean I should do like this instead:
public class Data {
public static DataSource getDataSource() {
// create a new datasource for each call to this method
return datasource;
}
}
Assuming that the 'datasource' object is still shared among threads,
it's still a bad idea. DataSource objects are not guaranteed to be
threadsafe, so you shoule not share them.
This is a bad example, because you should never cache the DataSource in
the first place: you should always get it from the JNDI tree.
- -chris
Ah... thanks Chris being able to
DataSource ds =
(DataSource)initContext.lookup(java:/comp/env/jdbc/xmecsDB);
from anywhere in the webapp would solve a lot of problems in that code...
Thanks...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
You aren't using any class-level
members in your static methods so you should be fine.
This means that I cannot declare a:
public class Data {
private static DataSource datasource = null;
public static DataSource getDataSource() {
if (datasource == null) {
// create a datasource
}
return datasource;
}
}
In the code above the class-level member is the datasource.
Do you mean I should do like this instead:
public class Data {
public static DataSource getDataSource() {
// create a new datasource for each call to this method
return datasource;
}
}
Date: Thu, 18 Sep 2008 11:56:33 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sinoea,
sinoea kaabi wrote:
The static methods are not thread-safe you say!
No, your static methods are perfectly threadsafe. Johnny is just getting
itchy because it's not what he'd do. You aren't using any class-level
members in your static methods so you should be fine.
Or in fact, you must be right, should I declare them synchronized?
No! This will limit your code to serialized database access, in which
case you are really only allowing a single connection to be used at a time.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjSejEACgkQ9CaO5/Lv0PDPUACggEWdUUKYajU1uRr8YgO/u+2J
//gAoLGPZqMvl6WDyEKQWnNkYpV2Tdrp
=ewSc
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Win New York holidays with Kellogg’s Live Search
http://clk.atdmt.com/UKM/go/111354033/direct/01/
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, September 19, 2008 9:18 AM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
You aren't using any class-level
members in your static methods so you should be fine.
This means that I cannot declare a:
public class Data {
private static DataSource datasource = null;
public static DataSource getDataSource() {
if (datasource == null) {
// create a datasource
}
return datasource;
}
}
In the code above the class-level member is the datasource.
Do you mean I should do like this instead:
public class Data {
public static DataSource getDataSource() {
// create a new datasource for each call to this method
return datasource;
}
}
---
Hi sinoea
If a datasource in DBCP represents the pool... you cant, you'd make a
million data pools...
These are the innocent looking things that can give problems...
The new trick to isolate the class global vars wont help in this case
So in theory... all access to that datasource variable should be synch'd...
In the routine you showing and in all the others that use it...
You dont sync at method level
public static DataSource getDataSource()
you just sync access to that shared global
The Java tut has examples of the various ways to sync method and code
sections...
As soon as more than one thread is sharing something... you either try
change the structure so that its not shared
or you sync it... it is normally too difficult to imagine the possible race
conditions...
The java tut has some example on just how tricky it can be as well...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Heres the blurb on the stuff... http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html/01/ Where I spoke about the New Trick... they blab on about immutable.. The stuff you prbably want to look at is Synchronized Statements In C they talk about semisphores and stuff... if you come from there, its that made easier... You cant jam sync statements everywhere... that will have some surprizing results as well... just where they needed... ... no expert... I just try avoid shared stuff to begin with ... the book has the truth ;) --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
If this measurement is made from the point of view of the DB server (I don't
think the OP ever said), the number if fine.
Actually if you look at the code in the OPs original post, you'll see
how the measurement is being made. It's essentially:
public static DataSource getDataSource() throws SQLException {
(snip ...)
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
(snip )
}
private static void logDataSource(final BasicDataSource ds) {
(snip ...)
DATASOURCE.info(The number of active connections are : +
ds.getNumActive());
DATASOURCE.info(The number of idle connections are : +
ds.getNumIdle());
(snip ...)
}
The numbers appear to be coming from the DBCP BasicDataSource itself.
--David
Caldarale, Charles R wrote:
From: Johnny Kewl [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active
connections keep increasing
sinoea, of course you can... that looks thread safe... but
what I'm trying to do, is just make it bullet proof...
Your suggestion does nothing to improve reliability, it just slows things
down by creating completely unnecessary do-nothing objects.
You leaking connections, we dont know why...
Actually we don't know it's leaking connections. All we know is that
somewhere in the overall system the number of connections is seen to be 37.
If this measurement is made from the point of view of the DB server (I don't
think the OP ever said), the number if fine. DBCP keeps the real connections
open for as long as the DB server permits; it's only if requests stall
because all the connections are busy (in use by other requests), then there's
a leak. I haven't read anything yet that indicates that's the case here.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sinoea, sinoea kaabi wrote: The static methods are not thread-safe you say! No, your static methods are perfectly threadsafe. Johnny is just getting itchy because it's not what he'd do. You aren't using any class-level members in your static methods so you should be fine. Or in fact, you must be right, should I declare them synchronized? No! This will limit your code to serialized database access, in which case you are really only allowing a single connection to be used at a time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSejEACgkQ9CaO5/Lv0PDPUACggEWdUUKYajU1uRr8YgO/u+2J //gAoLGPZqMvl6WDyEKQWnNkYpV2Tdrp =ewSc -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sinoea, sinoea kaabi wrote: Collection branches = new BranchData().loadBranches(Data.getDataSource(), 1); Can the getDataSource method be static? Not only can the getDataSource method be static, you could also call it directly from your loadBranches() method and make your interface simpler. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSen8ACgkQ9CaO5/Lv0PBJYgCgiix3mAHtfeiU7lSyIoL3q4mH 0MIAmwXwFqJX1efFRKVa1hI2kpcRchjg =Z3is -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Thanks,
First I will try to close resources before returning.
Although I am sure that the finally blocks are reached, since I use logging in
the last finally block and the log is
outputted.
try {
} finally {
connection.close();
Data.logConnection(connection); // this is logged
}
But I'll give it a try anyway.
Object object = null;
try {
} finally {
close resources..
}
return object;
The static methods are not thread-safe you say!
So, what exactly does it mean when we say that Tomcat is thread safe for
requests.
Tomcat creates a new thread for each request, so somehow my static methods
are then thread safe (incdirectly, since it is managed by Tomcat).
Request A new Thread A using my static method for loadBranches(...)
Request B new Thread B using my static method for loadBranches(...)
Thread B must wait until Thread A is done.
Since threads are managed by tomcat, no thread should be able to use a static
method that is used by another thread.
Or in fact, you must be right, should I declare them synchronized?
public static synchronized loadBranches(...)
Thanks,
Sinoea
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Tue, 16 Sep 2008 18:58:25 +0200
- Original Message -
From: Johnny Kewl [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:41 PM
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
- Original Message -
From: Brantley Hobbs [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:27 PM
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
return statements do not prevent the finally block from executing:
http://java.sun.com/docs/books/tutorial/essential/exceptions/finally.html
I stand corrected...
Always understood as during exception handling... but you right it seems
I just cant bring myself to write code like that... feels un-natural...
I would still put return after the close... apologies...
Ok sinoea, what I thought was just s little slip turns out to be right... I
actually tested it... that finally does run as the method loses scope... I
actually wonder how they do that... I imagine a destructor in a C class
underneath Java... its interesting, but I got to tell you, you doing the all
the good text bokk stuff, but the code makes me feel uncomfortable...
Anyway... I think you got a threading problem...
You using static class and servlets are multithreaded
Rather do something like this...
CollectionBranch branches = new
BranchData().loadBranches(Data.getDataSource(), 1);
and get rid of the static methods in that BranchData class
ie make it thread safe... at the moment you have multiple threads in that
static method... and with that finally I really dont know... haha
and then...
results.close();
statement.close();
connection.close();
return branches;
Would make me happy... and handle those exceptions
} catch (SQLException e) {
branch.setErrorMsg(Dear User, you have run out of
connections);
}finally{
//absolute critical stuff
}
But that really is just a style thing from the looks of things... although I
do think that with just a finally, you will still get a ungly servlet
exception...
ie you are definitely cleaning up... but you not telling the user why... its
style
You doing all the good stuff... but more important even if you forget a
final or two... is just a nice clean readable flow... I think ;)
We have a style clash ;)
Anyway thing your problem may go away once its thread safe ;)
Thanks... learnt something ;)
Will keep guessing till we get it ;)
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Make a mini you and download it into Windows Live Messenger
http://clk.atdmt.com/UKM/go/111354029/direct/01/
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, September 17, 2008 11:31 AM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Thanks,
First I will try to close resources before returning.
Although I am sure that the finally blocks are reached, since I use logging
in the last finally block and the log is
outputted.
try {
} finally {
connection.close();
Data.logConnection(connection); // this is logged
}
But I'll give it a try anyway.
Object object = null;
try {
} finally {
close resources..
}
return object;
The static methods are not thread-safe you say!
So, what exactly does it mean when we say that Tomcat is thread safe for
requests.
Tomcat creates a new thread for each request, so somehow my static methods
are then thread safe (incdirectly, since it is managed by Tomcat).
Request A new Thread A using my static method for loadBranches(...)
Request B new Thread B using my static method for loadBranches(...)
Thread B must wait until Thread A is done.
Since threads are managed by tomcat, no thread should be able to use a
static method that is used by another thread.
Or in fact, you must be right, should I declare them synchronized?
public static synchronized loadBranches(...)
Thanks,
Sinoea
=
Yes your finally blocks are working I checked that... the book is right
;)
On threading. No just make the class *non* static
CollectionBranch branches = *NEW*
BranchData().loadBranches(Data.getDataSource(), 1);
so now each thread has its own class.
I imagine thats tomcats pool is already thread safe...
synchronized will work... but its a bottle neck... it will make tomcat Q...
and there is a setting in tomcat somewhere where one can make it single
threaded... but again it will slow it down... you only use that when a coder
has cocked up ;)
In threading the thing to watch is those global variables... so without
seeing your actual code its difficult to spot problems...
Thread safety is more of an art than a science...
New should do it because every thread is getting its own class... so a class
is isolated, the connection and everything else is inside it... and they
cant mess with each other... in theory... if there are no shared globals...
So I think whats happening in your static class is something like this...
Thread 1 opens connection 1 inside class
Thread 2 open connection 2 also inside class
Close connection 2
Close connection 2
ie same connection is no closed twice and connection 1 slips out... that
wont happen if the class in not static...
I think ;)
have fun...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Sounds reasonable, I will give it a try with non-static methods instead, new
Dao() basically.
Thanks,
Sinoea
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Wed, 17 Sep 2008 12:25:17 +0200
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, September 17, 2008 11:31 AM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Thanks,
First I will try to close resources before returning.
Although I am sure that the finally blocks are reached, since I use logging
in the last finally block and the log is
outputted.
try {
} finally {
connection.close();
Data.logConnection(connection); // this is logged
}
But I'll give it a try anyway.
Object object = null;
try {
} finally {
close resources..
}
return object;
The static methods are not thread-safe you say!
So, what exactly does it mean when we say that Tomcat is thread safe for
requests.
Tomcat creates a new thread for each request, so somehow my static methods
are then thread safe (incdirectly, since it is managed by Tomcat).
Request A new Thread A using my static method for loadBranches(...)
Request B new Thread B using my static method for loadBranches(...)
Thread B must wait until Thread A is done.
Since threads are managed by tomcat, no thread should be able to use a
static method that is used by another thread.
Or in fact, you must be right, should I declare them synchronized?
public static synchronized loadBranches(...)
Thanks,
Sinoea
=
Yes your finally blocks are working I checked that... the book is right
;)
On threading. No just make the class *non* static
CollectionBranch branches = *NEW*
BranchData().loadBranches(Data.getDataSource(), 1);
so now each thread has its own class.
I imagine thats tomcats pool is already thread safe...
synchronized will work... but its a bottle neck... it will make tomcat Q...
and there is a setting in tomcat somewhere where one can make it single
threaded... but again it will slow it down... you only use that when a coder
has cocked up ;)
In threading the thing to watch is those global variables... so without
seeing your actual code its difficult to spot problems...
Thread safety is more of an art than a science...
New should do it because every thread is getting its own class... so a class
is isolated, the connection and everything else is inside it... and they
cant mess with each other... in theory... if there are no shared globals...
So I think whats happening in your static class is something like this...
Thread 1 opens connection 1 inside class
Thread 2 open connection 2 also inside class
Close connection 2
Close connection 2
ie same connection is no closed twice and connection 1 slips out... that
wont happen if the class in not static...
I think ;)
have fun...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Make a mini you and download it into Windows Live Messenger
http://clk.atdmt.com/UKM/go/111354029/direct/01/
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Just a question here,
I am using a Data class to retrieve the datasource
public class Data {
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new
InitialContext();
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming
exception when getting connection from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
}
Collection branches = new BranchData().loadBranches(Data.getDataSource(), 1);
Can the getDataSource method be static?
Thanks,
Sinoea
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Wed, 17 Sep 2008 12:25:17 +0200
- Original Message -
From: sinoea kaabi
To: Tomcat Users List
Sent: Wednesday, September 17, 2008 11:31 AM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Thanks,
First I will try to close resources before returning.
Although I am sure that the finally blocks are reached, since I use logging
in the last finally block and the log is
outputted.
try {
} finally {
connection.close();
Data.logConnection(connection); // this is logged
}
But I'll give it a try anyway.
Object object = null;
try {
} finally {
close resources..
}
return object;
The static methods are not thread-safe you say!
So, what exactly does it mean when we say that Tomcat is thread safe for
requests.
Tomcat creates a new thread for each request, so somehow my static methods
are then thread safe (incdirectly, since it is managed by Tomcat).
Request A new Thread A using my static method for loadBranches(...)
Request B new Thread B using my static method for loadBranches(...)
Thread B must wait until Thread A is done.
Since threads are managed by tomcat, no thread should be able to use a
static method that is used by another thread.
Or in fact, you must be right, should I declare them synchronized?
public static synchronized loadBranches(...)
Thanks,
Sinoea
=
Yes your finally blocks are working I checked that... the book is right
;)
On threading. No just make the class *non* static
Collection branches = *NEW*
BranchData().loadBranches(Data.getDataSource(), 1);
so now each thread has its own class.
I imagine thats tomcats pool is already thread safe...
synchronized will work... but its a bottle neck... it will make tomcat Q...
and there is a setting in tomcat somewhere where one can make it single
threaded... but again it will slow it down... you only use that when a coder
has cocked up ;)
In threading the thing to watch is those global variables... so without
seeing your actual code its difficult to spot problems...
Thread safety is more of an art than a science...
New should do it because every thread is getting its own class... so a class
is isolated, the connection and everything else is inside it... and they
cant mess with each other... in theory... if there are no shared globals...
So I think whats happening in your static class is something like this...
Thread 1 opens connection 1 inside class
Thread 2 open connection 2 also inside class
Close connection 2
Close connection 2
ie same connection is no closed twice and connection 1 slips out... that
wont happen if the class in not static...
I think ;)
have fun...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
A static method can't have access to class instance variables. You
could make it static, but it shouldn't reference any variables it didn't
locally declare:
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
Datasource ds = null ;
try {
Context initContext = new InitialContext();
ds = (DataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when
getting connection from tomcat pool: + e.getMessage());
}
}
--David
sinoea kaabi wrote:
Just a question here,
I am using a Data class to retrieve the datasource
public class Data {
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new
InitialContext();
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming
exception when getting connection from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
}
Collection branches = new BranchData().loadBranches(Data.getDataSource(), 1);
Can the getDataSource method be static?
Thanks,
Sinoea
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Wed, 17 Sep 2008 12:25:17 +0200
- Original Message -
From: sinoea kaabi
To: Tomcat Users List
Sent: Wednesday, September 17, 2008 11:31 AM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Thanks,
First I will try to close resources before returning.
Although I am sure that the finally blocks are reached, since I use logging
in the last finally block and the log is
outputted.
try {
} finally {
connection.close();
Data.logConnection(connection); // this is logged
}
But I'll give it a try anyway.
Object object = null;
try {
} finally {
close resources..
}
return object;
The static methods are not thread-safe you say!
So, what exactly does it mean when we say that Tomcat is thread safe for
requests.
Tomcat creates a new thread for each request, so somehow my static methods
are then thread safe (incdirectly, since it is managed by Tomcat).
Request A new Thread A using my static method for loadBranches(...)
Request B new Thread B using my static method for loadBranches(...)
Thread B must wait until Thread A is done.
Since threads are managed by tomcat, no thread should be able to use a
static method that is used by another thread.
Or in fact, you must be right, should I declare them synchronized?
public static synchronized loadBranches(...)
Thanks,
Sinoea
=
Yes your finally blocks are working I checked that... the book is right
;)
On threading. No just make the class *non* static
Collection branches = *NEW*
BranchData().loadBranches(Data.getDataSource(), 1);
so now each thread has its own class.
I imagine thats tomcats pool is already thread safe...
synchronized will work... but its a bottle neck... it will make tomcat Q...
and there is a setting in tomcat somewhere where one can make it single
threaded... but again it will slow it down... you only use that when a coder
has cocked up ;)
In threading the thing to watch is those global variables... so without
seeing your actual code its difficult to spot problems...
Thread safety is more of an art than a science...
New should do it because every thread is getting its own class... so a class
is isolated, the connection and everything else is inside it... and they
cant mess with each other... in theory... if there are no shared globals...
So I think whats happening in your static class is something like this...
Thread 1 opens connection 1 inside class
Thread 2
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, September 17, 2008 12:48 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Just a question here,
I am using a Data class to retrieve the datasource
public class Data {
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new InitialContext();
ds = (BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when getting connection
from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
}
=
Sineoa, my feeling is dont use static, unless you really want it in a
multithreaded environment
It pumps all the threads thru one pipe...
So yes I would *new* that as well...
But note this is where you will better be server by a DBCP user... because
we dont use it...
ie someone may say that declaring the Context as static is standard practice
and saves time... but I dont think so
You cant really go wrong by making it new... but you can get nailed by
making it static ;)
Have fun...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Thanks!
Date: Wed, 17 Sep 2008 08:01:01 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
A static method can't have access to class instance variables. You
could make it static, but it shouldn't reference any variables it didn't
locally declare:
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
Datasource ds = null ;
try {
Context initContext = new InitialContext();
ds = (DataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when
getting connection from tomcat pool: + e.getMessage());
}
}
--David
sinoea kaabi wrote:
Just a question here,
I am using a Data class to retrieve the datasource
public class Data {
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new
InitialContext();
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming
exception when getting connection from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
}
Collection branches = new BranchData().loadBranches(Data.getDataSource(),
1);
Can the getDataSource method be static?
Thanks,
Sinoea
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Wed, 17 Sep 2008 12:25:17 +0200
- Original Message -
From: sinoea kaabi
To: Tomcat Users List
Sent: Wednesday, September 17, 2008 11:31 AM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Thanks,
First I will try to close resources before returning.
Although I am sure that the finally blocks are reached, since I use logging
in the last finally block and the log is
outputted.
try {
} finally {
connection.close();
Data.logConnection(connection); // this is logged
}
But I'll give it a try anyway.
Object object = null;
try {
} finally {
close resources..
}
return object;
The static methods are not thread-safe you say!
So, what exactly does it mean when we say that Tomcat is thread safe for
requests.
Tomcat creates a new thread for each request, so somehow my static methods
are then thread safe (incdirectly, since it is managed by Tomcat).
Request A new Thread A using my static method for loadBranches(...)
Request B new Thread B using my static method for loadBranches(...)
Thread B must wait until Thread A is done.
Since threads are managed by tomcat, no thread should be able to use a
static method that is used by another thread.
Or in fact, you must be right, should I declare them synchronized?
public static synchronized loadBranches(...)
Thanks,
Sinoea
=
Yes your finally blocks are working I checked that... the book is right
;)
On threading. No just make the class *non* static
Collection branches = *NEW*
BranchData().loadBranches(Data.getDataSource(), 1);
so now each thread has its own class.
I imagine thats tomcats pool is already thread safe...
synchronized will work... but its a bottle neck... it will make tomcat Q...
and there is a setting in tomcat somewhere where one can make it single
threaded... but again it will slow it down... you only use that when a
coder
has cocked up ;)
In threading the thing to watch is those global variables... so without
seeing your actual code its difficult to spot problems...
Thread safety is more of an art than a science...
New should do it because every thread
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Johnny --
A properly written static method would be completely stateless and could
be executed from any number of threads simultaneously without issue.
Think old style function calls in C where stuff is created on the stack
and then popped off when execution finishes. The only hazard is if that
static method tries to access an object that isn't thread-safe -- then
you need sync blocks to protect the object.
--David
Johnny Kewl wrote:
- Original Message - From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, September 17, 2008 12:48 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Just a question here,
I am using a Data class to retrieve the datasource
public class Data {
/**
* Gets a [EMAIL PROTECTED] DataSource} for database connection usage.
* @return The datasource for database connection.
* @throws SQLException
*/
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new InitialContext();
ds = (BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when getting
connection from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
}
=
Sineoa, my feeling is dont use static, unless you really want it
in a multithreaded environment
It pumps all the threads thru one pipe...
So yes I would *new* that as well...
But note this is where you will better be server by a DBCP user...
because we dont use it...
ie someone may say that declaring the Context as static is standard
practice and saves time... but I dont think so
You cant really go wrong by making it new... but you can get nailed by
making it static ;)
Have fun...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
So, what exactly does it mean when we say that Tomcat is thread safe for requests. Tomcat creates a new thread for each request, so somehow my static methods are then thread safe (incdirectly, since it is managed by Tomcat). I actually searched all over to try find something for you this looks ok http://www.codestyle.org/java/servlets/faq-Threads.shtml But here my un-scientific way of thinking about it... When tomcat sends a thread into your doGet method... All those local variables in that thread are ok... So I think about it as each thread being a lane on a big freeway/highway... So yes you right in a way... Tomcat isnt allowing those local method variables to get mixed up... but the second you decalare a static method or static variable... you had better be sure its thread safe. What happens to that highway is that all the lanes merge into one, and every car has to go through it... When you add synchronized... your 30 lane high way becomes a single lane and its one car at a time... You dont want to add synchronized because here you have the TC guys gone thru all the hassle of making sure you can have a 30 lane highway... and you bang it into one lane so new is better because each lane gets its own engine... and java is pretty damn good at garbage collecting, that little bit of memory is a blip on the radar screen... You got to really know what your code is doing when its static... you got to know its thread safe, and it can be really hard to see that 30 car pile up coming on the highway ;) My way of thinking about this stuff. mad science - chapter 1 ;) --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Comments inline ... Johnny Kewl wrote: So, what exactly does it mean when we say that Tomcat is thread safe for requests. Tomcat creates a new thread for each request, so somehow my static methods are then thread safe (incdirectly, since it is managed by Tomcat). I actually searched all over to try find something for you this looks ok http://www.codestyle.org/java/servlets/faq-Threads.shtml But here my un-scientific way of thinking about it... When tomcat sends a thread into your doGet method... All those local variables in that thread are ok... As long as you mean variables defined inside of the doGet() method. Class instance variables are not cool in servlets. So I think about it as each thread being a lane on a big freeway/highway... But objects are not thread local unless they are setup that way implementing something like ThreadLocal. Only the references to the object are local. So yes you right in a way... Tomcat isnt allowing those local method variables to get mixed up... but the second you decalare a static method or static variable... you had better be sure its thread safe. Let's not confuse static methods and static variables. Static variables should be avoided unless they are true constants. Static methods on the other hand are fine, but need to be careful when those static methods interact with object instances that may not be thread safe. What happens to that highway is that all the lanes merge into one, and every car has to go through it... Now your are talking about a singleton -- a whole different ball of wax. When you add synchronized... your 30 lane high way becomes a single lane and its one car at a time... Still in singleton land with the one lane analogy. Syncs do add a huge performance penalty though, so even outside of singletons, syncs should be avoided as much as possible. You dont want to add synchronized because here you have the TC guys gone thru all the hassle of making sure you can have a 30 lane highway... and you bang it into one lane so new is better because each lane gets its own engine... and java is pretty damn good at garbage collecting, that little bit of memory is a blip on the radar screen... You got to really know what your code is doing when its static... you got to know its thread safe, and it can be really hard to see that 30 car pile up coming on the highway ;) My way of thinking about this stuff. mad science - chapter 1 ;) Johnny -- You might find the java language reference an interesting read. It describes all the rules regarding threading, access, value vs reference variables, etc., ... --David - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
From: Johnny Kewl [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing Sineoa, my feeling is dont use static, unless you really want it in a multithreaded environment It pumps all the threads thru one pipe... That's completely erroneous. There are only two differences between static and instance methods: 1) Static methods are not associated with any particular object instance of the the class (there is no this reference available to a static method). Static methods do have access to instance fields, if the method can obtain a reference to an instance (passed in as a parameter, static variable, etc.). 2) Static methods are not subject to polymorphism - there's no virtual invocation of them. Consequently, a reference to ClassA.method() will always resolve to ClassA.method(), regardless of any super- or sub-classes that ClassA might have. There's no pipe, narrowing highway, or any other throttling or queueing mechanism, nor should there be. Access to static fields, whether it be from static or instance variables must always be examined carefully for proper synchronization. As far as Tomcat being thread-safe, all that means is that Tomcat internals are guaranteed not to confuse things when multiple threads simultaneously call any of the defined servlet APIs, and that Tomcat will dispatch only one thread to handle a given request/response. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message - From: David Smith [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, September 17, 2008 3:40 PM Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing Comments inline ... Johnny Kewl wrote: So, what exactly does it mean when we say that Tomcat is thread safe for requests. Tomcat creates a new thread for each request, so somehow my static methods are then thread safe (incdirectly, since it is managed by Tomcat). I actually searched all over to try find something for you this looks ok http://www.codestyle.org/java/servlets/faq-Threads.shtml But here my un-scientific way of thinking about it... When tomcat sends a thread into your doGet method... All those local variables in that thread are ok... As long as you mean variables defined inside of the doGet() method. Class instance variables are not cool in servlets. So I think about it as each thread being a lane on a big freeway/highway... But objects are not thread local unless they are setup that way implementing something like ThreadLocal. Only the references to the object are local. No... ouch mention 2 words in a sentence and association kicks in ha ha I'm saying... These local variables are completely private; there is no way for one thread to access the local variables of another thread. Nothing at all to do with ThreadLocal... So yes you right in a way... Tomcat isnt allowing those local method variables to get mixed up... but the second you decalare a static method or static variable... you had better be sure its thread safe. Let's not confuse static methods and static variables. Static variables should be avoided unless they are true constants. Static methods on the other hand are fine, but need to be careful when those static methods interact with object instances that may not be thread safe. All true... but damn hard to see when you plugged into someone elses engine... ... in your own code in a static method, only have to worry about your globals... But someone elses code... not easy... unless they explicitly say thread safe. What happens to that highway is that all the lanes merge into one, and every car has to go through it... Now your are talking about a singleton -- a whole different ball of wax. No... I'm not... its actually your C analogy When you add synchronized... your 30 lane high way becomes a single lane and its one car at a time... Still in singleton land with the one lane analogy. Syncs do add a huge performance penalty though, so even outside of singletons, syncs should be avoided as much as possible. You dont want to add synchronized because here you have the TC guys gone thru all the hassle of making sure you can have a 30 lane highway... and you bang it into one lane so new is better because each lane gets its own engine... and java is pretty damn good at garbage collecting, that little bit of memory is a blip on the radar screen... You got to really know what your code is doing when its static... you got to know its thread safe, and it can be really hard to see that 30 car pile up coming on the highway ;) My way of thinking about this stuff. mad science - chapter 1 ;) Johnny -- You might find the java language reference an interesting read. It describes all the rules regarding threading, access, value vs reference variables, etc., ... Maybe you want to tell us why it is his code is leaking connections? What is it exactly in his code thats jumping a connection? Do you know? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
This question about static variables seems a bit deeper than I
thought, the more I think about it the more confused I get.
I could accept the fact that we should create new objects of Dao's,
but for getting a datasource or connection it should make sense
to have a utility class with static methods.
CollectionBranch branches = new BranchDao().loadBranches(
new DBUtil().getDataSource(), // This feels crap, I'd rather use
DBUtil.getDataSource() (without new)
1);
DBUtil should have static methods for retrieving a datasource or a connection,
creating a new DBUtil for each request does not feel right.
Well, you say that static methods don't necessarliy improve performance
in the long run, but why does the code at the bottom work for others.
And what is a thread-safe object:
An object whose state cannot be modified
So is a connection a thread-safe object or not?
It looks like you can modify its state (closing and opening it)
Below is a new connection object created, it is therefore
not a static class variable, only the method is static.
This means that the method should be thread safe, since a new connection
object is created for each thread.
public static Connection getConnection(){
try {
Context context =(Context) new InitialContext().lookup(java:comp/env);
DataSource dataSource = (DataSource) context.lookup(jdbc/FooBar);
Connection connection = dataSource.getConnection();
return connection;
} catch (NamingException namingException) {
log.fatal(namingException);
throw new RuntimeException(namingException);
} catch (SQLException sqlException) {
log.fatal(sqlException);
throw new RuntimeException(sqlException);
}
}
Date: Wed, 17 Sep 2008 09:40:16 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Comments inline ...
Johnny Kewl wrote:
So, what exactly does it mean when we say that Tomcat is thread
safe for
requests.
Tomcat creates a new thread for each request, so somehow my static
methods
are then thread safe (incdirectly, since it is managed by Tomcat).
I actually searched all over to try find something for you this
looks ok
http://www.codestyle.org/java/servlets/faq-Threads.shtml
But here my un-scientific way of thinking about it...
When tomcat sends a thread into your doGet method...
All those local variables in that thread are ok...
As long as you mean variables defined inside of the doGet() method.
Class instance variables are not cool in servlets.
So I think about it as each thread being a lane on a big
freeway/highway...
But objects are not thread local unless they are setup that way
implementing something like ThreadLocal. Only the references to the
object are local.
So yes you right in a way... Tomcat isnt allowing those local method
variables to get mixed up...
but the second you decalare a static method or static variable... you
had better be sure its thread safe.
Let's not confuse static methods and static variables. Static variables
should be avoided unless they are true constants. Static methods on the
other hand are fine, but need to be careful when those static methods
interact with object instances that may not be thread safe.
What happens to that highway is that all the lanes merge into one, and
every car has to go through it...
Now your are talking about a singleton -- a whole different ball of wax.
When you add synchronized... your 30 lane high way becomes a single
lane and its one car at a time...
Still in singleton land with the one lane analogy. Syncs do add a huge
performance penalty though, so even outside of singletons, syncs should
be avoided as much as possible.
You dont want to add synchronized because here you have the TC guys
gone thru all the hassle of making sure you can have a 30 lane
highway... and you bang it into one lane so new is better because
each lane gets its own engine... and java is pretty damn good at
garbage collecting, that little bit of memory is a blip on the radar
screen...
You got to really know what your code is doing when its static... you
got to know its thread safe, and it can be really hard to see that 30
car pile up coming on the highway ;)
My way of thinking about this stuff. mad science - chapter 1 ;)
Johnny -- You might find the java language reference an interesting
read. It describes all the rules regarding threading, access, value vs
reference variables, etc., ...
--David
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Discover Bird's Eye View now with Multimap
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Let's not get testy here -- your post had a lot of errors in it, including your concept of static methods and how they are handled in a threaded environment. This whole discussion is getting very off topic. I'll drop this thread here and respond to the OP on a thread that's still on topic. --David Johnny Kewl wrote: - Original Message - From: David Smith [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, September 17, 2008 3:40 PM Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing Comments inline ... Johnny Kewl wrote: So, what exactly does it mean when we say that Tomcat is thread safe for requests. Tomcat creates a new thread for each request, so somehow my static methods are then thread safe (incdirectly, since it is managed by Tomcat). I actually searched all over to try find something for you this looks ok http://www.codestyle.org/java/servlets/faq-Threads.shtml But here my un-scientific way of thinking about it... When tomcat sends a thread into your doGet method... All those local variables in that thread are ok... As long as you mean variables defined inside of the doGet() method. Class instance variables are not cool in servlets. So I think about it as each thread being a lane on a big freeway/highway... But objects are not thread local unless they are setup that way implementing something like ThreadLocal. Only the references to the object are local. No... ouch mention 2 words in a sentence and association kicks in ha ha I'm saying... These local variables are completely private; there is no way for one thread to access the local variables of another thread. Nothing at all to do with ThreadLocal... So yes you right in a way... Tomcat isnt allowing those local method variables to get mixed up... but the second you decalare a static method or static variable... you had better be sure its thread safe. Let's not confuse static methods and static variables. Static variables should be avoided unless they are true constants. Static methods on the other hand are fine, but need to be careful when those static methods interact with object instances that may not be thread safe. All true... but damn hard to see when you plugged into someone elses engine... ... in your own code in a static method, only have to worry about your globals... But someone elses code... not easy... unless they explicitly say thread safe. What happens to that highway is that all the lanes merge into one, and every car has to go through it... Now your are talking about a singleton -- a whole different ball of wax. No... I'm not... its actually your C analogy When you add synchronized... your 30 lane high way becomes a single lane and its one car at a time... Still in singleton land with the one lane analogy. Syncs do add a huge performance penalty though, so even outside of singletons, syncs should be avoided as much as possible. You dont want to add synchronized because here you have the TC guys gone thru all the hassle of making sure you can have a 30 lane highway... and you bang it into one lane so new is better because each lane gets its own engine... and java is pretty damn good at garbage collecting, that little bit of memory is a blip on the radar screen... You got to really know what your code is doing when its static... you got to know its thread safe, and it can be really hard to see that 30 car pile up coming on the highway ;) My way of thinking about this stuff. mad science - chapter 1 ;) Johnny -- You might find the java language reference an interesting read. It describes all the rules regarding threading, access, value vs reference variables, etc., ... Maybe you want to tell us why it is his code is leaking connections? What is it exactly in his code thats jumping a connection? Do you know? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
To get this thread restarted in the right direction, I thought it'd be
good to recap a little from your posts so far...
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back
to the pool,
eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections
are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
3. An idle connection can only be idle for an X amount of time and then
it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection
when calling connection.close()
To comment on #3, there is nothing to force destroy a connection at a
set age. It's good until a test of the connection fails and then it's
closed. That's what the validationQuery is for. On that note, it's be
good to add validationQuery=select 1 to your Resource ... /
definition so connections are tested before they get loaned out.
That'll prevent problems at the 8 hour mark for MySQL db connections.
To comment on #4, I would also expect that which is why it's interesting
you see the behavior you do. It's also interesting you see the pool
fill even when idle which implies *something* is grabbing a connection
and not necessarily closing it properly. Might be time to run a
profiler on it and see exactly where pool connections are getting
borrowed and returned.
--David
sinoea kaabi wrote:
This question about static variables seems a bit deeper than I
thought, the more I think about it the more confused I get.
I could accept the fact that we should create new objects of Dao's,
but for getting a datasource or connection it should make sense
to have a utility class with static methods.
CollectionBranch branches = new BranchDao().loadBranches(
new DBUtil().getDataSource(), // This feels crap, I'd rather use
DBUtil.getDataSource() (without new)
1);
DBUtil should have static methods for retrieving a datasource or a connection,
creating a new DBUtil for each request does not feel right.
Well, you say that static methods don't necessarliy improve performance
in the long run, but why does the code at the bottom work for others.
And what is a thread-safe object:
An object whose state cannot be modified
So is a connection a thread-safe object or not?
It looks like you can modify its state (closing and opening it)
Below is a new connection object created, it is therefore
not a static class variable, only the method is static.
This means that the method should be thread safe, since a new connection
object is created for each thread.
public static Connection getConnection(){
try {
Context context =(Context) new
InitialContext().lookup(java:comp/env);
DataSource dataSource = (DataSource) context.lookup(jdbc/FooBar);
Connection connection = dataSource.getConnection();
return connection;
} catch (NamingException namingException) {
log.fatal(namingException);
throw new RuntimeException(namingException);
} catch (SQLException sqlException) {
log.fatal(sqlException);
throw new RuntimeException(sqlException);
}
}
Date: Wed, 17 Sep 2008 09:40:16 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Comments inline ...
Johnny Kewl wrote:
So, what exactly does it mean when we say that Tomcat is thread
safe for
requests.
Tomcat creates a new thread for each request, so somehow my static
methods
are then thread safe (incdirectly, since it is managed by Tomcat).
I actually searched all over to try find something for you this
looks ok
http://www.codestyle.org/java/servlets/faq-Threads.shtml
But here my un-scientific way of thinking about it...
When tomcat sends a thread into your doGet method...
All those local variables in that thread are ok...
As long as you mean variables defined inside of the doGet() method.
Class instance variables are not cool in servlets.
So I think about it as each thread being a lane on a big
freeway/highway...
But objects are not thread local unless they are setup that way
implementing something like ThreadLocal. Only the references to the
object are local.
So yes you right in a way... Tomcat isnt allowing those local method
variables to get mixed up...
but the second you decalare a static method or static variable... you
had better be sure its thread safe.
Let's not confuse static methods and static variables. Static variables
should be avoided unless they are true constants
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, September 17, 2008 4:48 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
This question about static variables seems a bit deeper than I
thought, the more I think about it the more confused I get.
I could accept the fact that we should create new objects of Dao's,
but for getting a datasource or connection it should make sense
to have a utility class with static methods.
CollectionBranch branches = new BranchDao().loadBranches(
new DBUtil().getDataSource(), // This feels crap, I'd rather use
DBUtil.getDataSource() (without new)
1);
DBUtil should have static methods for retrieving a datasource or a
connection,
creating a new DBUtil for each request does not feel right.
Well, you say that static methods don't necessarliy improve performance
in the long run, but why does the code at the bottom work for others.
And what is a thread-safe object:
An object whose state cannot be modified
So is a connection a thread-safe object or not?
It looks like you can modify its state (closing and opening it)
Below is a new connection object created, it is therefore
not a static class variable, only the method is static.
This means that the method should be thread safe, since a new connection
object is created for each thread.
public static Connection getConnection(){
try {
Context context =(Context) new
InitialContext().lookup(java:comp/env);
DataSource dataSource = (DataSource) context.lookup(jdbc/FooBar);
Connection connection = dataSource.getConnection();
return connection;
} catch (NamingException namingException) {
log.fatal(namingException);
throw new RuntimeException(namingException);
} catch (SQLException sqlException) {
log.fatal(sqlException);
throw new RuntimeException(sqlException);
}
}
sinoea, of course you can... that looks thread safe... but what I'm trying
to do, is just make it bullet proof...
You leaking connections, we dont know why... so idea is to try take any
threading issues out of the equation...
Then you run it, it works... you play with the code...add your routines
back... find whats causing it...
and then you going to tell us why it was leaking thats what we
dying to know;)
You wont be the first person that stared at a piece of code for 2 days and
not seen the threading issue...
It can be really hard to spot...
If a person gives you a class and says... this is NOT thread safe... what
you going to do with it?
Thats the thing I'm showing you...
David right, I'm no teacher... but I've done it a million times... send me
your code, I'll find the problem for you...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message - From: sinoea kaabi [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, September 17, 2008 4:48 PM Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing This question about static variables seems a bit deeper than I thought, the more I think about it the more confused I get. I could accept the fact that we should create new objects of Dao's, but for getting a datasource or connection it should make sense to have a utility class with static methods. CollectionBranch branches = new BranchDao().loadBranches( new DBUtil().getDataSource(), // This feels crap, I'd rather use DBUtil.getDataSource() (without new) 1); DBUtil should have static methods for retrieving a datasource or a connection, creating a new DBUtil for each request does not feel right. -- Are you an ex C programmer Sounds like it... theres a couple strange feeling things in Java... String x = new Thing(); in a loop is something else you see a C programmer wants to stick the declaration outside the loop... so its easy to clean up java nah... that garbage collector is pure magic ;) You get used of it... There is a pretty good threading tut in the famous Java Tutorial... Normal stuff, like race conditions... yada yada... its good reading but when you actually doing it... its a feeling... because its a timing issue. No error message that says anything... just wrong values. --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Johnny Kewl wrote: So, what exactly does it mean when we say that Tomcat is thread safe for requests. Tomcat creates a new thread for each request, so somehow my static methods are then thread safe (incdirectly, since it is managed by Tomcat). I actually searched all over to try find something for you this looks ok http://www.codestyle.org/java/servlets/faq-Threads.shtml But here my un-scientific way of thinking about it... When tomcat sends a thread into your doGet method... All those local variables in that thread are ok... So I think about it as each thread being a lane on a big freeway/highway... So yes you right in a way... Tomcat isnt allowing those local method variables to get mixed up... but the second you decalare a static method or static variable... you had better be sure its thread safe. What happens to that highway is that all the lanes merge into one, and every car has to go through it... When you add synchronized... your 30 lane high way becomes a single lane and its one car at a time... You dont want to add synchronized because here you have the TC guys gone thru all the hassle of making sure you can have a 30 lane highway... and you bang it into one lane so new is better because each lane gets its own engine... and java is pretty damn good at garbage collecting, that little bit of memory is a blip on the radar screen... You got to really know what your code is doing when its static... you got to know its thread safe, and it can be really hard to see that 30 car pile up coming on the highway ;) My way of thinking about this stuff. mad science - chapter 1 ;) Johnny, you really have your own style of writing, to which we've all gotten used to on this list. But this one was really nice. Very understandable and fun. Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Caldarale, Charles R wrote: That's completely erroneous. Shame, Johnny's story was so nice.. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, September 17, 2008 9:56 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Right, I have attached the source code.
I have included the whole package with the database classes.
Also, I have included the package with three action classes, in reality
there are more action classes but it would be a nightmare,
and also the database classes are used quiet similarly in other action
classes.
This is a Struts web application, so action classes are used.
= Arrrg not our favorite... should be fun
Notice on some database classes where I use the connection in several inner
methods:
public static void doSomething(datasource) {
Connection connection = datasource.getConnection();
try {
innerMethod(connection);
anotherInnerMethod(connection);
} finally {
connection.close(); // should be OK to use the connection in
inner classes, as the connection gets finally closed.
}
}
private static void innerMethod(connection) {
Statetement statement = connection.createStatement();
try {
} finally {
statement.close();
}
}
If you spot a problem then FANTASTIC.
I have had this problem for years and I really want to solve the problem
now.
Also, I would be grateful if you could let me know how you design your
database classes.
= Everything is ours we dont use frameworks
= Pools, Persistence... all our own stuff... makes it kind of easy to find
problems ;)
The whole pattern and usage basically.
= KISS... keep it simple stupid ;)
= Basic TC MVC patterns... you can read up on them on the web... MVC
methodology, not a framework
CoreServlets has some nice articles
Thanks for putting up with me so far
= Hey I'm bored stiff... our banks are still running here... ha ha...
= Its almost midnight here... we'll play with it in the morning... looks
like you on the same time zone
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, September 17, 2008 10:18 PM Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing Caldarale, Charles R wrote: That's completely erroneous. Shame, Johnny's story was so nice.. I didnt even get to toll booths on the highway... when the threads have to all stop there, thats the global variable, can be dangerous, if you sharing one with oncoming traffic ;) No doubt not a chapter in the University Java Hand Book ;) --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sinoea,
sinoea kaabi wrote:
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
I typically put this all together so I don't have too many try/catch
blocks when they're really not required:
Connection conn = null;
Statement statement = null;
ResultSet results = null;
try
{
...
}
catch (SQLException ...)
{
...
}
... other exceptions ...
finally
{
if(null != results)
try { results.close(); } catch (SQLException sqle)
{ ... log exception ... }
if(null != statement)
try { statement.close(); } catch (SQLException sqle)
{ ... log exception ... }
if(null != connection)
try { connection.close(); } catch (SQLException sqle)
{ ... log exception ... }
}
Remember that it's important to put try/catch blocks around the close
invocations -- and make sure to log any errors you get. Otherwise, a
SQLException from closing your connection could mask a more serious
exception occurring elsewhere.
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
You might also want to set:
validationQuery=SELECT 1
Are you not seeing any log messages about abandoned connections?
logAbandoned should be enabling that.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjRdsUACgkQ9CaO5/Lv0PDz5QCfXKQp7Koz/OFmEZm68exHTxFV
YMAAn2EPmXYtrS+eHFGx39Bp90TX4lOK
=8euf
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sinoea,
Oh, and I always always /always/ set my connection pool size to a fixed
size of 1 (yes, a single connection) in development. This can help find
places where you are requesting two connections from the pool by a
single thread, which exposes you to a deadlock scenario.
If you want to test if your logAbandoned logging is working, here's a
simple JSP that will leak a connection for you ;)
- -chris
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
[EMAIL PROTECTED] language=Java
isErrorPage=false
import=
java.sql.*,
java.util.*,
java.io.PrintWriter,
javax.naming.Context,
javax.naming.InitialContext,
javax.naming.NamingException,
javax.sql.DataSource
%
%!
/**
* Gets a JDBC connection. This implementation uses JNDI to obtain a
* connection. Feel free to substitute your own.
*/
Connection getConnection()
throws SQLException, javax.naming.NamingException
{
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup((your JNDI name));
if(null == ds)
throw new NamingException(Cannot obtain DataSource);
return ds.getConnection();
}
%
%
Connection conn = getConnection();
%
html
body
pGot connection: %= conn %/p
pNow, I refuse to give it away!/p
/body
/html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjReDoACgkQ9CaO5/Lv0PC/FwCfZPybusC0jzBeKYoD93xMyTbI
3XUAn1HUJWUjrfoZipIVXubV7MqPYPB/
=qfKA
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Sounds like you're not explicitly killing off the connections you set in
the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back to
the pool,
eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections
are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and not
yet returned back to the pool
2. An active connection will be returned back to the pool
straight after its usage and become an idle connection
The active connection is returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and then
it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection
when calling connection.close()
If that is all correct then why do my active connections keep
increasing?
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
Context
Resource
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
/Context
[/code]
My Host configuration in server.xml
[code]
Host name=www.mysite.com deployOnStartup=true debug=0
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
Valve
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software
Foundation/Tomcat 5.5/webapps/mysite/logs/
Aliasmysite.com/Alias
/Host
[/code]
Here is the class that I use the get the datasource
[code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql);
private static final Logger DATASOURCE =
Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger(manyconnections);
private static BasicDataSource ds = null;
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new InitialContext();
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when
getting connection from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
/**
* Logs the datasource.
* @param ds
*/
private static void logDataSource(final BasicDataSource ds) {
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
How exaclt do you mean?
Anywhere in my code where you have seen that?
Thanks!
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Tue, 16 Sep 2008 10:26:03 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sounds like you're not explicitly killing off the connections you set in
the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back to
the pool,
eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections
are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and not
yet returned back to the pool
2. An active connection will be returned back to the pool
straight after its usage and become an idle connection
The active connection is returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and then
it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection
when calling connection.close()
If that is all correct then why do my active connections keep
increasing?
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
[/code]
My Host configuration in server.xml
[code]
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software
Foundation/Tomcat 5.5/webapps/mysite/logs/
mysite.com
[/code]
Here is the class that I use the get the datasource
[code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql);
private static final Logger DATASOURCE =
Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger(manyconnections);
private static BasicDataSource ds = null;
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new InitialContext();
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when
getting connection from tomcat pool: + e.getMessage());
}
} else {
logDataSource(ds);
return ds;
}
}
/**
* Logs the datasource.
* @param ds
*/
private static void logDataSource(final BasicDataSource ds) {
DATASOURCE.info(The max active connections are : +
ds.getMaxActive());
DATASOURCE.info(The max idle connections are : +
ds.getMaxIdle());
DATASOURCE.info(The max wait is : + ds.getMaxWait());
DATASOURCE.info(The max opening prepared statements are : +
ds.getMaxOpenPreparedStatements());
DATASOURCE.info(The number of active connections are : +
ds.getNumActive());
DATASOURCE.info
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
At the end of the servlet or JSP or whichever, you need to kill off
connections created that you establish.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 9:56 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
How exaclt do you mean?
Anywhere in my code where you have seen that?
Thanks!
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 10:26:03 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sounds like you're not explicitly killing off the connections you set
in the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back
to the pool, eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and
not yet returned back to the pool
2. An active connection will be returned back to the pool straight
after its usage and become an idle connection The active connection is
returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and
then it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection when
calling connection.close()
--
--
If that is all correct then why do my active connections keep
increasing?
--
--
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
[/code]
My Host configuration in server.xml
[code]
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software Foundation/Tomcat
5.5/webapps/mysite/logs/ mysite.com
[/code]
Here is the class that I use the get the datasource [code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql); private
static final Logger DATASOURCE = Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger(manyconnections);
private static BasicDataSource ds = null;
public static DataSource getDataSource() throws SQLException { if (ds
== null) { DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL ); try { final Context
initContext = new InitialContext(); ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when getting
connection from tomcat pool: + e.getMessage()); } } else {
logDataSource(ds); return ds; } }
/**
* Logs the datasource.
* @param ds
*/
private static void logDataSource(final BasicDataSource ds) {
DATASOURCE.info(The max active connections
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Yes, as I said in the first post, that I have checked through all the code,
and I am closing all the connections (in a finally block) after they have been
used.
final Connection connection = datasource.getConnection();
try {
...
..
blah .. blah
} finally {
connection.close();
}
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Tue, 16 Sep 2008 11:02:46 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
At the end of the servlet or JSP or whichever, you need to kill off
connections created that you establish.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 9:56 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
How exaclt do you mean?
Anywhere in my code where you have seen that?
Thanks!
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 10:26:03 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sounds like you're not explicitly killing off the connections you set
in the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back
to the pool, eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and
not yet returned back to the pool
2. An active connection will be returned back to the pool straight
after its usage and become an idle connection The active connection is
returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and
then it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection when
calling connection.close()
--
--
If that is all correct then why do my active connections keep
increasing?
--
--
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
[/code]
My Host configuration in server.xml
[code]
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software Foundation/Tomcat
5.5/webapps/mysite/logs/ mysite.com
[/code]
Here is the class that I use the get the datasource [code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql); private
static final Logger DATASOURCE = Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger(manyconnections);
private static BasicDataSource ds = null;
public static DataSource getDataSource() throws SQLException { if (ds
== null) { DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL ); try { final Context
initContext = new InitialContext(); ds =
(BasicDataSource)initContext.lookup
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:10 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Yes, as I said in the first post, that I have checked through all the code,
and I am closing all the connections (in a finally block) after they have
been used.
final Connection connection = datasource.getConnection();
try {
BUT you have a
return branches;
HERE
It can never get to HERE
Just put the return after the finally
blah .. blah
} finally {
connection.close();
}
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Date: Tue, 16 Sep 2008 11:02:46 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
At the end of the servlet or JSP or whichever, you need to kill off
connections created that you establish.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 9:56 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
How exaclt do you mean?
Anywhere in my code where you have seen that?
Thanks!
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 10:26:03 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sounds like you're not explicitly killing off the connections you set
in the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back
to the pool, eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and
not yet returned back to the pool
2. An active connection will be returned back to the pool straight
after its usage and become an idle connection The active connection is
returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and
then it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection when
calling connection.close()
--
--
If that is all correct then why do my active connections keep
increasing?
--
--
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
[/code]
My Host configuration in server.xml
[code]
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software Foundation/Tomcat
5.5/webapps/mysite/logs/ mysite.com
[/code]
Here is the class that I use the get the datasource [code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql); private
static final Logger DATASOURCE = Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
return statements do not prevent the finally block from executing:
http://java.sun.com/docs/books/tutorial/essential/exceptions/finally.html
B.
Johnny Kewl wrote:
- Original Message - From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:10 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Yes, as I said in the first post, that I have checked through all the
code,
and I am closing all the connections (in a finally block) after they
have been used.
final Connection connection = datasource.getConnection();
try {
BUT you have a
return branches;
HERE
It can never get to HERE
Just put the return after the finally
blah .. blah
} finally {
connection.close();
}
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 11:02:46 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
At the end of the servlet or JSP or whichever, you need to kill off
connections created that you establish.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 9:56 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
How exaclt do you mean?
Anywhere in my code where you have seen that?
Thanks!
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 10:26:03 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sounds like you're not explicitly killing off the connections you set
in the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back
to the pool, eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and
not yet returned back to the pool
2. An active connection will be returned back to the pool straight
after its usage and become an idle connection The active connection is
returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and
then it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection when
calling connection.close()
--
--
If that is all correct then why do my active connections keep
increasing?
--
--
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
[/code]
My Host configuration in server.xml
[code]
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software Foundation/Tomcat
5.5/webapps/mysite/logs/ mysite.com
[/code]
Here is the class that I use the get the datasource [code]
import...
public class Data {
private static final Logger SQL
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Yeah, that should be closing itwould you be establishing the
connection(s) anywhere else though?
And do you have a ResultsSet that you're leaving open? You would need to
close that, too.
Same for any prepared or callable statement as well.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 10:10 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Yes, as I said in the first post, that I have checked through all the
code, and I am closing all the connections (in a finally block) after
they have been used.
final Connection connection = datasource.getConnection();
try {
...
..
blah .. blah
} finally {
connection.close();
}
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 11:02:46 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
At the end of the servlet or JSP or whichever, you need to kill off
connections created that you establish.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 9:56 AM
To: Tomcat Users List
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
How exaclt do you mean?
Anywhere in my code where you have seen that?
Thanks!
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
Date: Tue, 16 Sep 2008 10:26:03 -0400
From: [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sounds like you're not explicitly killing off the connections you set
in the first place.
-Original Message-
From: sinoea kaabi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 4:24 AM
To: users@tomcat.apache.org
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted
scenario,
where there were no connections left to use, and now I am getting a
different problem.
I have been digging in this issue for too long, and I am not sure if
I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back
to the pool, eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I
have
ever had)
After a few days, the active connections reach to 37, and then
afterwards the active connections are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so
on
My understanding is that:
1. An active connection is a connection that is currently used, and
not yet returned back to the pool
2. An active connection will be returned back to the pool straight
after its usage and become an idle connection The active connection
is
returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for connection pooling)
3. An idle connection can only be idle for an X amount of time and
then it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection
when
calling connection.close()
--
--
If that is all correct then why do my active connections keep
increasing?
--
--
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
[/code]
My Host configuration in server.xml
[code]
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software Foundation/Tomcat
5.5/webapps/mysite/logs/ mysite.com
[/code]
Here is the class that I use the get the datasource [code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message - From: Brantley Hobbs [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, September 16, 2008 5:27 PM Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing return statements do not prevent the finally block from executing: http://java.sun.com/docs/books/tutorial/essential/exceptions/finally.html I stand corrected... Always understood as during exception handling... but you right it seems I just cant bring myself to write code like that... feels un-natural... I would still put return after the close... apologies... --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
sinoea I dont use the JNDI pools, but I've marked a possible issue below...
Dont think its getting to finally guess ;)
On the dB pools I use... connections will not increase... unless that many
threads are used at same time..
ie the connections represent a max activity level... otherwise it wont
increase...
... why it resets at 37 I dont know, but I think you are leaking
connections...
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 11:23 AM
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario, where
there
were no connections left to use, and now I am getting a different problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back to the
pool,
eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have ever
had)
After a few days, the active connections reach to 37, and then afterwards
the active connections
are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and not
yet returned back to the pool
2. An active connection will be returned back to the pool
straight after its usage and become an idle connection
The active connection is returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured for
connection pooling)
3. An idle connection can only be idle for an X amount of time and then
it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection
when calling connection.close()
If that is all correct then why do my active connections keep increasing?
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
Context
Resource
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
/Context
[/code]
My Host configuration in server.xml
[code]
Host name=www.mysite.com deployOnStartup=true debug=0
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
Valve
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software Foundation/Tomcat
5.5/webapps/mysite/logs/
Aliasmysite.com/Alias
/Host
[/code]
Here is the class that I use the get the datasource
[code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql);
private static final Logger DATASOURCE = Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger(manyconnections);
private static BasicDataSource ds = null;
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context initContext = new InitialContext();
ds =
(BasicDataSource)initContext.lookup(java:/comp/env/jdbc/myDB);
initContext.close();
logDataSource(ds);
return ds;
} catch (final NamingException e) {
e.printStackTrace();
throw new RuntimeException(Java naming exception when
getting connection from tomcat pool: + e.getMessage());
}
}
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: Johnny Kewl [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:17 PM
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:10 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Yes, as I said in the first post, that I have checked through all the
code,
and I am closing all the connections (in a finally block) after they have
been used.
final Connection connection = datasource.getConnection();
try {
BUT you have a
return branches;
HERE
It can never get to HERE
Just put the return after the finally
blah .. blah
} finally {
connection.close();
}
sinoea
in the context of exceptions finally is always run... exception or
not...
BUT...
you still have to let the program get there
... you returning too early the connections are not closing...
Have fun...
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
Yeah, it sounds that wayalmost like passing off one query to another
servlet or page, and then the leak occurs.
Do you have a monitoring tool that you can see the connections increase?
-Original Message-
From: Johnny Kewl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 8:37 AM
To: Tomcat Users List
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections
keep increasing
sinoea I dont use the JNDI pools, but I've marked a possible issue
below...
Dont think its getting to finally guess ;)
On the dB pools I use... connections will not increase... unless that
many threads are used at same time..
ie the connections represent a max activity level... otherwise it wont
increase...
... why it resets at 37 I dont know, but I think you are leaking
connections...
- Original Message -
From: sinoea kaabi [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 11:23 AM
Subject: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
Dear all,
I seem to have problems with connection pooling.
I have tried so many ways, before I use to get the exhausted scenario,
where
there
were no connections left to use, and now I am getting a different
problem.
I have been digging in this issue for too long, and I am not sure if I
understand the depth of the connection pooling concept.
I have set the max active connections to 40.
My active connections keep increasing, they never seem to return back to
the
pool,
eventhough when no-one is visiting the site.
(Well, I have had up to 3 idle connections and that is the most I have
ever
had)
After a few days, the active connections reach to 37, and then
afterwards
the active connections
are reset to 0.
It basically starts from 0 to 37 and then again 0 to 37, and so on
My understanding is that:
1. An active connection is a connection that is currently used, and not
yet returned back to the pool
2. An active connection will be returned back to the pool
straight after its usage and become an idle connection
The active connection is returned back to the pool as soon as you
call the connection.close() method (assuming that you have configured
for
connection pooling)
3. An idle connection can only be idle for an X amount of time and then
it will be removed from the pool and get destroyed
4. An idle connection will become an active connection when it is
required and then returned back to the pool as an idle connection
when calling connection.close()
If that is all correct then why do my active connections keep
increasing?
Am I closing all the connections?
Well, I have checked every single line of code, and yes I am closing
result sets, statements and connections in a finally block:
[code]
} finally {
results.close();
}
} finally {
statement.close();
}
} finally {
connection.close();
}
[/code]
Please have a look at my code and configuration below:
My environment:
JDK 1.5.0_12
Tomcat 5.5.27
MySQL 5
My Web apps context.xml under the META-INF folder:
[code]
Context
Resource
name=jdbc/myDB
factory=org.apache.commons.dbcp.BasicDataSourceFactory
auth=Container
type=javax.sql.DataSource
maxActive=40
maxIdle=10
maxWait=15000
removeAbandoned=true
removeAbandonedTimeout=60
logAbandoned=true
username=username
password=password
driverClassName=com.mysql.jdbc.Driver
url=jdbc:mysql://localhost:3306/mydb /
/Context
[/code]
My Host configuration in server.xml
[code]
Host name=www.mysite.com deployOnStartup=true debug=0
appBase=webapps/mysite unpackWARs=true autoDeploy=false
xmlValidation=false xmlNamespaceAware=false
Valve
className=org.apache.catalina.valves.FastCommonAccessLogValve
prefix=mysite_access_log.
suffix=.txt
pattern=common
directory=C:/Program Files/Apache Software
Foundation/Tomcat
5.5/webapps/mysite/logs/
Aliasmysite.com/Alias
/Host
[/code]
Here is the class that I use the get the datasource
[code]
import...
public class Data {
private static final Logger SQL = Logger.getLogger(sql);
private static final Logger DATASOURCE =
Logger.getLogger(datasource);
private static final Logger MANY_CONNECTIONS =
Logger.getLogger(manyconnections);
private static BasicDataSource ds = null;
public static DataSource getDataSource() throws SQLException {
if (ds == null) {
DATASOURCE.info(DataSource is NULL );
MANY_CONNECTIONS.info(DataSource is NULL );
try {
final Context
Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep increasing....
- Original Message -
From: Johnny Kewl [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:41 PM
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
- Original Message -
From: Brantley Hobbs [EMAIL PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, September 16, 2008 5:27 PM
Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing
return statements do not prevent the finally block from executing:
http://java.sun.com/docs/books/tutorial/essential/exceptions/finally.html
I stand corrected...
Always understood as during exception handling... but you right it seems
I just cant bring myself to write code like that... feels un-natural...
I would still put return after the close... apologies...
Ok sinoea, what I thought was just s little slip turns out to be right... I
actually tested it... that finally does run as the method loses scope... I
actually wonder how they do that... I imagine a destructor in a C class
underneath Java... its interesting, but I got to tell you, you doing the all
the good text bokk stuff, but the code makes me feel uncomfortable...
Anyway... I think you got a threading problem...
You using static class and servlets are multithreaded
Rather do something like this...
CollectionBranch branches = new
BranchData().loadBranches(Data.getDataSource(), 1);
and get rid of the static methods in that BranchData class
ie make it thread safe... at the moment you have multiple threads in that
static method... and with that finally I really dont know... haha
and then...
results.close();
statement.close();
connection.close();
return branches;
Would make me happy... and handle those exceptions
} catch (SQLException e) {
branch.setErrorMsg(Dear User, you have run out of
connections);
}finally{
//absolute critical stuff
}
But that really is just a style thing from the looks of things... although I
do think that with just a finally, you will still get a ungly servlet
exception...
ie you are definitely cleaning up... but you not telling the user why... its
style
You doing all the good stuff... but more important even if you forget a
final or two... is just a nice clean readable flow... I think ;)
We have a style clash ;)
Anyway thing your problem may go away once its thread safe ;)
Thanks... learnt something ;)
Will keep guessing till we get it ;)
---
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
