Hi Chris -- We have access to the configuration files, but not the source code. There is no "pool" reference in server.xml or any of the context.xml files. However, I did receive a call from a vendor tech this morning and they are exploring the question right now and will get back to me soon hopefully.
> -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Monday, January 3, 2022 9:10 AM > To: users@tomcat.apache.org > Subject: Re: Do I Need Network NameSpaces to Solve This > Tomcat+Connector/J Problem? > > Eric, > > On 12/30/21 19:03, Eric Robinson wrote: > > If I want to ignore the vendor's recommendation and try connection > > pooling anyway, is that something I can enable with a config file > > setting, or do they actually have to trigger it from within their > > code? > That depends upon how they are obtaining database connections. If they are > using the driver directly and NOT using a pool (why would they use a pool if > they have a policy NOT to use it?) then there is likely nothing you can do. > > Are you able to look at the code? Are you able to look at the configuration? > Specifically, the META-INF/context.xml file in the application and > conf/server.xml for the server. > > If we can find a "pool" configuration in there, it's possible it just has > insane > limits like maxActive="1000000000" or something like that. > > -chris > > >> -----Original Message----- > >> From: Eric Robinson <eric.robin...@psmnv.com> > >> Sent: Thursday, December 30, 2021 12:00 PM > >> To: Tomcat Users List <users@tomcat.apache.org> > >> Subject: RE: Do I Need Network NameSpaces to Solve This > >> Tomcat+Connector/J Problem? > >> > >> Chris, > >> > >>> Not pooling connections will very likely negatively affect performance. > >>> > >>> When you say "they ... have an issue with connection pooling" do you > >>> mean that they have a technical problem, or do you mean that there > >>> is some ill- conceived policy against them? > >>> > >>> Oh, maybe they are paranoid about cross-client leakage between > >>> connections. Well, if the application can't be trusted not to leak > >>> that kind of info, then it can't be trusted to make the connections > >>> properly in the first place. > >>> > >>> -chris > >>> > >> > >> Hard to say what their issue is. We've asked about implementing it > >> before, but they don't support it. You know how software companies > >> are. Maybe they had a technical problem with it years ago and have just > not revisited it. > >> They're stuck in a rut and there is too much inertia to get them out of it. > >> > >> --Eric > >> > >> > >> > >> > >> Disclaimer : This email and any files transmitted with it are > >> confidential and intended solely for intended recipients. If you are > >> not the named addressee you should not disseminate, distribute, copy > >> or alter this email. Any views or opinions presented in this email > >> are solely those of the author and might not represent those of > >> Physician Select Management. Warning: Although Physician Select > >> Management has taken reasonable precautions to ensure no viruses are > >> present in this email, the company cannot accept responsibility for any > loss or damage arising from the use of this email or attachments. > > Disclaimer : This email and any files transmitted with it are confidential > > and > intended solely for intended recipients. If you are not the named addressee > you should not disseminate, distribute, copy or alter this email. Any views or > opinions presented in this email are solely those of the author and might not > represent those of Physician Select Management. Warning: Although > Physician Select Management has taken reasonable precautions to ensure > no viruses are present in this email, the company cannot accept responsibility > for any loss or damage arising from the use of this email or attachments. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
