Re: Tomcat 4 JDBCRealm Connection Pooling
On Wed, 13 Feb 2002, Glenn Nielsen wrote: Date: Wed, 13 Feb 2002 10:25:07 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tomcat 4 JDBCRealm Connection Pooling Currently the JDBCRealm does not use db Connection Pooling, instead it maintains an open connection and synchronizes use of the connection. I have been using the new Tomcat 4.1-dev DBCP for creating a JNDI named JDBC DataSource and it has been working well. The easiest way to implement db connection pooling may be by providing a JDBC Realm which uses a JNDI named JDBC DataSource. Should this support be added to the current JDBCRealm, or should a new realm be created which uses a JNDI named JDBC DataSource? Hi Glenn, Personally, I like the latter idea better (a new JDBCRealm implementation that uses a JNDI named data source) to avoid disruption of existing applications. Regards, Glenn Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 4 JDBCRealm Connection Pooling
-Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Glenn Nielsen Enviado el: miércoles 13 de febrero de 2002 17:25 Should this support be added to the current JDBCRealm, or should a new realm be created which uses a JNDI named JDBC DataSource? I think it's better to create a new Realm ( PooledJDBCRealm ? DataSourceRealm ? ) to conserve backwards compatibility.. Maybe inheriting from JDBCRealm have any sense? most of the config options available in JDBCRealm are not usefull in a DataSource Realm .. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4 JDBCRealm Connection Pooling
On Wed, 13 Feb 2002, Glenn Nielsen wrote: Hi Glenn, Personally, I like the latter idea better (a new JDBCRealm implementation that uses a JNDI named data source) to avoid disruption of existing applications. Yes, I agree. Internal Catalina components can now use JNDI in the HEAD branch. So the DataSource could be defined in GlobalNamingResources, and the realm should be able to use it. This DataSource could be shared by more components. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4 JDBCRealm Connection Pooling
On Wed, 13 Feb 2002, Glenn Nielsen wrote: Date: Wed, 13 Feb 2002 11:53:52 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Tomcat 4 JDBCRealm Connection Pooling Remy Maucherat wrote: On Wed, 13 Feb 2002, Glenn Nielsen wrote: Hi Glenn, Personally, I like the latter idea better (a new JDBCRealm implementation that uses a JNDI named data source) to avoid disruption of existing applications. Yes, I agree. Internal Catalina components can now use JNDI in the HEAD branch. So the DataSource could be defined in GlobalNamingResources, and the realm should be able to use it. This DataSource could be shared by more components. A global JDBC DataSource for Realms may work for some, but when virtual hosting websites and applications for different customers I need a different Realm for each customer. That way each customer has their own name space for userid's and roles. You can still use JNDI resources for this -- just set up as many different connection pools as you need (under different names), and attach the JDBCDataSourceRealm for each application to the appropriate connection pool name. In the HEAD branch, I used the same basic technique for configuring the UserDatabaseRealm in the default server.xml file. It is configured with the global resource name of the UserDatabase implementation to use (default configuration value is java:UserDatabase). For per-host or per-webapp user databases, I would simply set up some more of these, under different resource names, and connect the UserDatabaseRealm for each webapp appropriately. (Speaking of which, we might also consider writing a JDBCUserDatabase implementation as well -- that way, the admin webapp can be used to update the users in a database instead of in conf/tomcat-users.xml like MemoryUserDatabase does.) In addition I use a different DataSource for normal customer dB application data and realm data. The separation of these data sources makes sure that a customer application can't be spoofed somehow to compromise the entries in the db for a realm. This is all easy to set up. It's also easy to set up a scenario where a single connection pool, configured in the global resources, is actually shared by the JDBCDataSourceRealm and made available to an application (through a ResourceLink) if that is what your application requires. Regards, Glenn Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4 JDBCRealm Connection Pooling
On Wed, 13 Feb 2002, Glenn Nielsen wrote: [snip] The addition of GlobalNamingResources and the UserDatabase slipped below my radar somehow. I looked at the latest server.xml from CVS. I grep'd the docs in CVS and didn't notice anything in the docs about these yet. The addition of GlobalNamingResources and the UserDatabase does add some interesting possiblities when configuring resources in Tomcat 4. (Speaking of which, we might also consider writing a JDBCUserDatabase implementation as well -- that way, the admin webapp can be used to update the users in a database instead of in conf/tomcat-users.xml like MemoryUserDatabase does.) How would you like to proceed with this and the JDBCDataSourceRealm? I think we need both JDBCDataSourceRealm (that supports the same database configurability as JDBCRealm) and JDBCUserDatabase (which will have to make more stringent restrictions on the table structures in use). In addition I use a different DataSource for normal customer dB application data and realm data. The separation of these data sources makes sure that a customer application can't be spoofed somehow to compromise the entries in the db for a realm. This is all easy to set up. It's also easy to set up a scenario where a single connection pool, configured in the global resources, is actually shared by the JDBCDataSourceRealm and made available to an application (through a ResourceLink) if that is what your application requires. Do you have an example of this? I am very interested in being able to reduce the number of DBCP required, yet keep a complete separation of resources made available between virtual hosts. Here's a scenario, and the way you might configure it: - Define a connection pool in the Global JNDI resources - Make it available to a theoretical JDBCDataSourceRealm - Make it available to an application as a JNDI resource named jdbc/MyDatabase. In web.xml, the application would declare a resource-ref for the resource named jdbc/MyDatabase in the usual way. In server.xml, you would configure like this: Server ... !-- Configure a JDBC connection pool in the global resources -- GlobalNamingResources Resource name=TheDatabase auth=Container type=javax.sql.DataSource/ ResourceParams name=TheDatabase ... configure the connection pool in the usual way ... /ResourceParams /GlobalNamingResources !-- Configure a Realm that uses this underlying connection pool -- Realm className=org.apache.catalina.realm.JDBCDataSourceRealm resourceName=java:TheDatabase/ !-- Configure a data source using the same underlying pool -- Context path=/myapp ... ... ResourceLink name=jdbc/MyDatabase global=TheDatabase/ ... /Context /Server Doing things this way lets you substitute data source implementations underneath either the server component (JDBCDataSourceRealm) or the application, or change the decision about whether you are sharing the same data source or not, without impacting any of the code that uses it. As an additional advantage, the admin webapp will ultimately include a nice UI to configure the global reosurces for you, plus a way to create the resource links. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
