DB connection pooling webpage mistake
Hi, I noticed that the code for the connection pooling had been changed, but I can see that theres a copy and paste error here, the if statement checks for 'ctx' being null twice, instead of checking for ds being null the second time. As you can see in the code I copied off the page: InitialContext cxt = new InitialContext(); if ( cxt == null ) { throw new Exception(Uh oh -- no context!); } DataSource ds = (DataSource) cxt.lookup( java:/comp/env/jdbc/postgres ); if ( cxt == null ) { throw new Exception(Data source not found!); } A small error, but might cause problems for people copying it. :D Robert Clarkson Broadmedia Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DB connection pooling webpage mistake
Hi, Fixed in CVS. Thanks for pointing it out, Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com -Original Message- From: Robert Clarkson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 5:06 AM To: tomcat-dev@jakarta.apache.org Subject: DB connection pooling webpage mistake Hi, I noticed that the code for the connection pooling had been changed, but I can see that theres a copy and paste error here, the if statement checks for 'ctx' being null twice, instead of checking for ds being null the second time. As you can see in the code I copied off the page: InitialContext cxt = new InitialContext(); if ( cxt == null ) { throw new Exception(Uh oh -- no context!); } DataSource ds = (DataSource) cxt.lookup( java:/comp/env/jdbc/postgres ); if ( cxt == null ) { throw new Exception(Data source not found!); } A small error, but might cause problems for people copying it. :D Robert Clarkson Broadmedia Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35200] - Tomcat connection pooling fault with MySql derived tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35200. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35200 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-16 11:12 --- Great. Problems about the JDBC pool (which happens to be commons-dbcp) that are not configuration issues with Tomcat or similar should be discussed on the appropriate commons mailing list, or reported as commons-dbcp bugs (but you should probably provide a little bit more details). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35200] - Tomcat connection pooling fault with MySql derived tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35200. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35200 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2005-06-16 13:13 --- A mistake in the code was found, so not a bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35200] New: - Tomcat connection pooling fault with MySql derived tables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35200. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35200 Summary: Tomcat connection pooling fault with MySql derived tables Product: Tomcat 5 Version: 5.5.7 Platform: Other OS/Version: Windows 2000 Status: NEW Severity: blocker Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When using Tomcats connection pooling a query using derived tables seems to loop infinately with a jumble of the first records of result set. When same query run stand-alone using JDBC, works fine. eg: SELECT a.col1, b.col2 FROM table1 a, (SELECT col1 FROM table2) b WHERE a.col1=b.col1; servlet.xml Resource name=jdbc/local type=javax.sql.DataSource password=password driverClassName=org.gjt.mm.mysql.Driver maxIdle=10 maxWait=15000 validationQuery=select count(*) from usermaster username=username url=jdbc:mysql://localhost:3306/dbname?autoReconnect=true maxActive=100/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31381] - password for connection pooling problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31381. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31381 password for connection pooling problem [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-09-24 15:01 --- This is a known issue: see the data for the duplicate one. $'s are interpreted ;( *** This bug has been marked as a duplicate of 29823 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Connection Pooling
hi , IS there is any way to Connect Database using DBCP.jar without giving username and password in the server.xml file. Doc tells that we can pass the uname and password in the getConnection() method of DataSource . But it is give me an Exception . Plese help me. sathya _ It's new, it's here! It's full of fun! http://server1.msn.co.in/sp03/messengerpromo/index.asp MSN Messenger V6.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection Pooling
This list is for developing the tomcat server. Your question is a configuration question and should be directed to the tomcat-user list. Martin On Monday, July 21, 2003, at 02:00 PM, sathya narayanan wrote: hi , IS there is any way to Connect Database using DBCP.jar without giving username and password in the server.xml file. Doc tells that we can pass the uname and password in the getConnection() method of DataSource . But it is give me an Exception . Plese help me. sathya _ It's new, it's here! It's full of fun! http://server1.msn.co.in/sp03/messengerpromo/index.asp MSN Messenger V6.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10852] - Patch: Add Connection Pooling to JNDIRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10852. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10852 Patch: Add Connection Pooling to JNDIRealm [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-02-12 15:36 --- Closing bug since patch is old (and submitted by me). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDBCStore Connection Pooling
insert newbie disclaimers here I have been trying to use the JDBCStore stuff and found it to be a little unstable especially when the database connections have problems (or when the database is bounced). So, I decided to make some modifications that would allow it to drop connections on SQLExceptions and maintain a small connection pool (LinkedList of Connections). Should I post the patch to this forum? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCStore Connection Pooling
A better solution might be to have a Store which can use a JNDI named DataSource. Then let the DataSource worry about connection pooling, etc. Glenn Tom Anderson wrote: insert newbie disclaimers here I have been trying to use the JDBCStore stuff and found it to be a little unstable especially when the database connections have problems (or when the database is bounced). So, I decided to make some modifications that would allow it to drop connections on SQLExceptions and maintain a small connection pool (LinkedList of Connections). Should I post the patch to this forum? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCStore Connection Pooling
True, that might be a better design but my motivation was for a quick fix with minimal impact to the design. On Thursday, January 30, 2003, at 01:25 PM, Glenn Nielsen wrote: A better solution might be to have a Store which can use a JNDI named DataSource. Then let the DataSource worry about connection pooling, etc. Glenn Tom Anderson wrote: insert newbie disclaimers here I have been trying to use the JDBCStore stuff and found it to be a little unstable especially when the database connections have problems (or when the database is bounced). So, I decided to make some modifications that would allow it to drop connections on SQLExceptions and maintain a small connection pool (LinkedList of Connections). Should I post the patch to this forum? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBCStore Connection Pooling
, that might be a better design but my motivation was for a quick fix with minimal impact to the design. On Thursday, January 30, 2003, at 01:25 PM, Glenn Nielsen wrote: A better solution might be to have a Store which can use a JNDI named DataSource. Then let the DataSource worry about connection pooling, etc. Glenn Tom Anderson wrote: insert newbie disclaimers here I have been trying to use the JDBCStore stuff and found it to be a little unstable especially when the database connections have problems (or when the database is bounced). So, I decided to make some modifications that would allow it to drop connections on SQLExceptions and maintain a small connection pool (LinkedList of Connections). Should I post the patch to this forum? ~Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12952] New: - Documentation error for Tyrex Connection Pooling
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12952. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12952 Documentation error for Tyrex Connection Pooling Summary: Documentation error for Tyrex Connection Pooling Product: Tomcat 4 Version: 4.1.10 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Resource name=my-datasource auth=Container type=tyrex.resource.Resource/ ResourceParams name=my-datasource parameter namename/name valuemyDataSource/name /parameter /ResourceParams Notice the value is closed by name rather than value -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: connection pooling
Monitor the database connectivity at your RDBMS. Most of the time you can watch the connection construction and all the queries running across one connection. - Andrew -Original Message- From: Pop Marius [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 5:00 AM To: tomcat Subject: connection pooling Hi everybody ! I'm using Tomcat 4 and my application works. To get a connection to database I have the following code: Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource)envCtx.lookup(jdbc/orgDB); return ds.getConnection(); and of course in the server.xml the necessary resource requirements ! The application works fine, but How could I ensure myself that the connections provided are reused, that the pooling machine works, and I really have a pooling mechanism. How can I test it ! The documentation sais that ds.getConnection() gets a connection from the pool (which pool, how) but I'm not sure that ! Any idea would be helpful ! Pop Marius Lucian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: connection pooling
On Thu, 25 Jul 2002, Pop Marius wrote: Date: Thu, 25 Jul 2002 11:00:05 +0200 From: Pop Marius [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: tomcat [EMAIL PROTECTED] Subject: connection pooling Hi everybody ! I'm using Tomcat 4 and my application works. To get a connection to database I have the following code: Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource)envCtx.lookup(jdbc/orgDB); return ds.getConnection(); and of course in the server.xml the necessary resource requirements ! The application works fine, but How could I ensure myself that the connections provided are reused, that the pooling machine works, and I really have a pooling mechanism. How can I test it ! The documentation sais that ds.getConnection() gets a connection from the pool (which pool, how) but I'm not sure that ! It gets a connection from the pool that you configured with your resource settings in server.xml. Any idea would be helpful ! The normal pattern for using a connection from a data source like this (including your code from above): Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource) envCtx.lookup(jdbc/orgDB); Connection conn= ds.getConnextion(); ... use the connection to do your database access ... conn.close(); The last call doesn't actually close the underlying database connection -- it just returns this instance to the connection pool. Pop Marius Lucian Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: connection pooling
Use a monitoring tool on your RDBMS. For SQL Server I use Profiler. - Andrew -Original Message- From: Pop Marius [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 5:00 AM To: tomcat Subject: connection pooling Hi everybody ! I'm using Tomcat 4 and my application works. To get a connection to database I have the following code: Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup(java:comp/env); DataSource ds = (DataSource)envCtx.lookup(jdbc/orgDB); return ds.getConnection(); and of course in the server.xml the necessary resource requirements ! The application works fine, but How could I ensure myself that the connections provided are reused, that the pooling machine works, and I really have a pooling mechanism. How can I test it ! The documentation sais that ds.getConnection() gets a connection from the pool (which pool, how) but I'm not sure that ! Any idea would be helpful ! Pop Marius Lucian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10852] New: - Patch: Add Connection Pooling to JNDIRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10852. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10852 Patch: Add Connection Pooling to JNDIRealm Summary: Patch: Add Connection Pooling to JNDIRealm Product: Tomcat 4 Version: 4.1.7 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Attached (soon) will be a patch which add connection pooling to JNDIRealm. The pool used is from jakarta-commons/pool. The number of connections and amount of time for eviction of pool items are configurable. The javadocs have been updated too to reflect my additions. No new functionality has been introduced. The down side is testing for good connections. There is none. But bad connectinos are removed by waiting for bad things to happening - then remembering the connection later to be closed. The pool factory is implmented as an inner class. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10852] - Patch: Add Connection Pooling to JNDIRealm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10852. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10852 Patch: Add Connection Pooling to JNDIRealm --- Additional Comments From [EMAIL PROTECTED] 2002-07-16 01:51 --- Created an attachment (id=2359) Patch file as promised -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9480] - Data connection pooling
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9480 Data connection pooling [EMAIL PROTECTED] changed: What|Removed |Added Summary|Data connection pooiling|Data connection pooling -- 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 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
It would be nice to reference the JDBC data source rather than configuring the realm seperately. The problem I see is that the Realm is global in server.xml and the data sources are specific to individual contexts. Should the realm be moved into the context so that different contexts could be configured with different realms? Jonathan Reply Separator Subject:Tomcat 4 JDBCRealm Connection Pooling Author: Tomcat Developers List [EMAIL PROTECTED] Date: 2/13/2002 10:25 AM 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? Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This email and any files transmitted with it are for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. This email message has been swept by a virus software product for the presence of computer viruses. * -- 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]