On 02/27/2015 11:59 AM, Christopher Schultz wrote: > Red, > > On 2/27/15 11:04 AM, Red wrote: > > On 02/27/2015 06:58 AM, Антон Мацюк wrote: > >> 2015-02-27 1:36 GMT+02:00 Mark Thomas <ma...@apache.org>: > >>> On 26/02/2015 22:56, Christopher Schultz wrote: > >>> > >>>> The solution is to put your <Resource> into your > >>>> application's > >>> s/The solution/The best solution/ > >>> > >>>> context.xml and not into the site-wide defaults. Konstantin > >>>> may not have spelled-out the solution, but he did give you > >>>> all the information you needed to come to that conclusion on > >>>> your own. > >>> Another (not so good because your application is no longer > >>> self-contained) option is to define a global resource and put > >>> a ResourceLink into the global context.xml or the application's > >>> context.xml. > >> > >> About "not so good because your application is no longer > >> self-contained" - this is normal in case when tomcat is an > >> sysadmin headache, and admin is bearing responsibility for both > >> tomcat and pool in it works well. As a programmer - my job is to > >> connect to provided datasource, and use it normally. So best > >> approach in this situation will be use of GlobalNamingResources > >> > http://tomcat.apache.org/tomcat-7.0-doc/config/globalresources.html#Environment_Entries > >> > >> > to store there my jdbc-pools and just make ResourceLink > >> > http://tomcat.apache.org/tomcat-7.0-doc/config/globalresources.html#Resource_Links > >> > >> > in application's META_INF/context.xml to get this datasource from > >> global context. > >> > >> --------------------------------------------------------------------- > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > Thank You all; I have come to same conclusions, though they vastly > > differ from what I have expected. I have found spare Oracle Linux > > 6.5 machine , downloaded latest tomcat 8.0.20, java is 1.7.0_65. > > Behaviour is the same, tomcat opens 50 conenctions to database. > > After moving pool definition from conf/context.xml to > > webapps/manager/META-INF/context.xml, tomcat opens 10 connections. > > Reading, then, this is default value of pool initial size (tenth of > > maxActive, default 100). > > You have maxActive="10". The default value of initialSize is supposed > to be "0". I'm surprised it's opening 10 connections immediately. > > > After explicitly defining initialSize="1", only single connection > > is opened. Good. Now moving that pool definition back to > > conf/context.xml, I get five connections to db. There is total 5 > > apps deployed by default (ROOT. manager, hostmanager, docs and > > examples). Basically, each app opens every connection pool defined > > in conf/context.xml to the tune of initialSize. > > Correct. This is exactly what you have asked Tomcat to do: define a > default DataSource for all web applications. Note that it's *not a > shared data source between all the web applications*. Instead, it's a > DataSource that will be created for *each web application you deploy*. > > So, if the DataSource opens up 10 connections and you have 10 web > applications, you'll get 100 connections to the database. > > (I'm not exactly sure why they are being opened immediately, but you > are in fact getting 10 DataSources.) > > > At my place we have about 25 applications in each dev and prod, > > with about 10-15 database pools defined. Even with initialSize set > > to 1, that comes to total over 300 connections, which makes > > conf/context.xml useless for me. If so, connections pools must be > > moved to application context.xml. > > You should be doing this anyway. It's very rare for a whole server > full of applications to need the same DataSource configuration(s). > > > Well, this is maintenance nightmare for me, as passwords are > > changed regularly, and I have to edit every single app context.xml > > file. > > Learn to script things. > > > On top of it, we deploy .war files, and context.xml are part of > > it. > > If you use a separate deployment descriptor in > conf/[engine]/[hostname]/[appname].xml, then the deployment descriptor > in the WAR file will be ignored. > > > In dev, I do not care, but for production, .war has to be packed > > with context.xml in it (with conn info). > > Does it? > > > As a dba, I refuse to give prod passwords to developers > > Then don't. > > > So I will have to package/repackage not only on initial > > deployment, but on every app update. > > Untrue. See above. > > > Please tell me that I am wrong > > You are wrong. > > > because as it look now whole purpose of connection pooling is > > defeated, and that can not be. Hostmanager (for example) does not > > have any oracle connection defined within itself, so why it should > > even know those exist, not to mention to actually open them. > > Agreed. Stop defining DataSources in conf/context.xml. > > When you deploy an application, your application's > META-INF/context.xml and conf/context.xml are merged and treated as > "/the/ configuration" for the application. So stop defining default > application configuration if you don't want it to be the default > application configuration. > > > I will do reading on this, suggested above first, but my objective > > is clear. Single file with all pools, apps ask for and use/open > > only pools needed. I believe that is how it was in tomcat6. > > If you want a single file with all pools, you'll need to configure a > global resource in server.xml and then map them into each web > application using <ResourceLink>(s). Note that changing the DataSource > configuration will require you to restart the *whole container* > instead of just the application if you want to change it. > > > If anyone knows how to achieve this please let me know (I did not > > have chance yet to go though links provided since yesterday, so my > > answer might be there). > > -chris
Thank you Chris, Jeffrey, Антон, Mark and other who responded; Chris answer really solves it for me, though I had to do some reading and basic testing before answering. Thank you all again, Red --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
