Rob,
On 12/3/20 17:46, Rob Sargent wrote:
Again, much appreciated feedback. (I never think what I'm doing is all
that special)
At this point, the fact that you are using embedded Tomcat is really
just a detail that doesn't affect the greater question of how to manage
your complex database pooling needs.
Though two concurrent users would really be "wildly successful", each of
those users will fire up hundreds (thousands if we get
permission/capacity) of EC2 instances and start pounding the db, so I
think connection pooling is in order.
What do those EC2 instances actually do? Do they connect to your
application (which connects to the db), or do they connect directly to
the db?
I contemplated managing my own pools but didn't want
- the hassle of resetting the "search_path" for each connection if I
used a single (initial) user (if I stuck with the tomcat pooler)
- the overhead in terms of both my own code and actual resource
consumption(minimum connection held etc)
I would highly recommend that you abstract this away from your
application with some kind of utility method like:
public Connection getConnection(whatever args you need);
Then you can change that method to do whatever is necessary. Maybe it's
determine which pool to use, and use it. Maybe it's create a new
connection every single time. Maybe it's a mixture of the two.
so I switched to the dbcp2 PerUserPoolDataSourceFactory in the hope that
the lookup for an available connection happens after I reset the user/db
I think Phil said that doesn't work. You can call
getConnection(username,password) but it won't pool those connections. I
haven't read the code, but I suspect that is what happens.
If you need to switch *databases*, there really is no way to do that.
Besides, you'd never want to restrict yourself to using the *same*
database connection(s) for more than one database, would you? You'd
never be able to separate the databases onto separate servers, clusters,
etc.
I seem to recall that tomcat-pool can actually do this, but maybe it
just implements the API and also just hands you a fresh connection every
time with your username and password. (i.e. not actually pooling).
(Recall that with postgres a db is just part of the same physical
server, of which there will be only one and for me a user is associated
with only one database.)
Maybe you want to consider a multi-tenant database
(tablespace/schema/etc.) instead of having a distinct one for each customer.
Another option would be to spin-up a separate application (instance) for
each customer, each with its own one-and-only-one db connection pool.
Really great to hear that lookup() is not my biggest concern;)
;)
-chris
On 12/3/20 3:18 PM, Christopher Schultz wrote:
Rob,
On 12/3/20 11:03, Rob Sargent wrote:
Thanks for you time. Your response goes a long way to explaining why
there is so little specific information on embedding tomcat.
Only programmers are interested in using embedded Tomcat, so having
"Tomcat Embedded For Dummies" isn't terribly useful. (I don't mean to
be insulting; I'm just trying to get my point across about
"intro-level" content regarding Tomcat as an embedded product.)
Embedding Tomcat into a product is done precisely because the standard
deployment model (which lends itself to system admins who don't really
need to know anything about Java programming) isn't sufficient for
some special-case. Indeed, every Tomcat embedded instance is by
definition a special-case so guides for "doing it" don't exist since
nobody else knows exactly what you are trying to do.
Really, just as I said. I had convinced myself from several items
encountered on the web that an embedded tomcat instance would not
read the standard conf/*.xml. If I hit any of those pages again I
will react (either on the page or perhaps post here, if that would be
appropriate).
The best references for behavior of the Tomcat class would be:
1. The Tomcat javadoc
and
2. The source code for the Tomcat class
It's fairly readable, but most everything you need to read is in the
Javadoc.
TL/DR: at heart I’m struggling with the proper initialization and
consumption of the dbpc2 datasource which I add programmatically and
might consider using the context.xml version.
Unless there is a particularly good reason not to use it, I would
recommend using META-INF/context.xml. There are some really great
reasons not to do that. For example, if you want to fetch your DBCP
configuration from Kubernetes and then use that to
dynamically-configure DBCP, then you'll probably have to forego
XML-based configuration.
A litany of small issues: >
My @Resource(name, type) Datasource ds” doesn’t take (I have several
more attempts planned)
Ooh. I tend to avoid @Annotations and I'm not really sure how that one
works, anyway. I'm not a good resource, here.
Is that failure logged?
Dunno.
Is context.lookup() expensive?
No. Tomcat's implementation of JNDI contexts isn't much more
complicated than a HashMap. In some other EE containers,
context.lookup() might indeed be expensive.
Is there any configuration available only in xml?
I don't know for sure, but I suspect not. The XML configuration uses
the commons-digester to call setFoo("bar") for each foo="bar"
attribute on the <Resource>, so I don't think there is anything in
there what couldn't be done 100% in Java code. You might have to
dig-around a little to find the default implementations of various
things (like DataSource/DataSourceFactory) but that shouldn't be too
tough.
DriverManager is working fine but it that the best access to the
DataSource, which I need to be able to change the current database
(in a postgres sense)
Do you need to change the user after container-initialization, like
potentially for any given request? Is there anything wrong with
registering multiple database pools and then selecting the right one
depending upon the effective user during the request?
Maybe you don't even want a connection pool. I remember you saying
you'd be wildly successful if you had 2 users per day or something
like that.
-chris
On Dec 3, 2020, at 8:06 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
Rob,
On 12/2/20 13:31, Rob Sargent wrote:
I'm old and easily confused: does an embedded tomcat server read
(any) context.xml file? I find conflicting answers /out there./
Using tomcat 9.0.40
embeddedTomcat =new Tomcat();
embeddedTomcat.setPort(tomcatPort);
embeddedTomcat.enableNaming();
embeddedTomcat.getConnector();// an init, really String
contextRootPath =System.getenv("CATALINA_HOME");
Context contextTomcat =embeddedTomcat.addContext("",new
File(contextRootPath +"/sgs").getAbsolutePath());
I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
servlets, none of which are named in the web.xml.
Tomcat should be reading your web application's META-INF/context.xml
file, if one exists.
If you call Tomcat.init(), it will attempt to locate the default
conf/server.xml, conf/web.xml, and conf/context.xml based upon your
configuration source.
What are you /really/ asking?
-chris
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
