RE: Are all TC-managed DataSources pooled?
Thanks for your comments Doug. Good point re relevance of javax.sql API docs. I had a search through the J2EE spec. It does not appear to me to _require_ that DataSources are provided in a pooled implementation. It seems to be preferred. For example: J2EE.5.4.3 (J2EE Product Provider's Responsibilities) says, While not required by this specification, most J2EE products will provide the following features:.. A mechanism to pool resources for the application components and otherwise manage the use of resources by the container. The pooling must be transparent to the application components. J2EE6.2.4.3 (JDBC API) says, The JDBC API includes APIs for ... connection pooling ... The connection pooling and distributed transaction features are intended for use by JDBC drivers to coordinate with an application server. J2EE products are not required to support the application server facilities described by these APIs, although they may prove useful. Can anyone point me at a section of J2EE that says that pooling is required for container-managed DataSources? Also there are the other Qs in my last post - including, what is the effect of including this: parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter as suggested at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-how to.html compared to not including a factory param at all? To reiterate, my original issue is that I'm trying to understand whether or not TC *always* pools container-managed DataSources. -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: Thursday 11 November 2004 02:37 To: Tomcat Users List Subject: Re: Are all TC-managed DataSources pooled? Is every container-managed DataSource configured in TC (e.g. via server.xml / context.xml) automatically made pooled using commons pooling? Yes. No additional code is needed (i.e. TC takes care of the pool.) Or can ordinary non-pooled connections be created too using this mechanism? No, as it would not be compliant. It might be possible to create a pool of one connection, but it would still be handled as a pool. To answer your original questions: Now, I'm *not* criticising the docs, I'm seeking clarification. I'm not sure whether this is saying that a JDBC DataSource has to be pooled? Or is instead saying that J2EE requires pooled JDBC connections, or maybe that J2EE requires connections via a DataSource? To meet the J2EE requirement the DataSource method must be made avalible in a pooled configuration. I didn't think that DataSources had to be pooled, based on what is says here: http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/DataSource.html This is only the API for the language. The language may be able to do many things that are not compliant with the J2EE standard reguarding the server. Think about if you were writing a stand alone desktop app and had it talking to a datasource. The J2EE requirements for the server are of no interest and don't apply. This might sound like nit picking, but the answer to this will help me help someone else on another thread. Thanks. Hope they get the picture. Doug www.parsonstechnical.com - 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]
RE: Are all TC-managed DataSources pooled?
Hi, I already answered this... Maybe my post was lost. I had a search through the J2EE spec. It does not appear to me to _require_ that DataSources are provided in a pooled implementation. It seems to be preferred. For example: You're right. Containers are required to support binding of a DataSource, but it doesn't have to be pooling. Most implementations give the user the choice, as does Tomcat. You can use DBCP in non-pooling ways (set maxActive to infinite), or use any DataSource implementation whether it supports pooling or not. Also there are the other Qs in my last post - including, what is the effect of including this: parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter That's effectively required for Tomcat to be able to create org.apache.commons.dbcp.BasicDataSource instances. The general JNDI approach in Tomcat is factory-based (this has since been replicated in many other server implementations), where the provider impl includes a factory, so Tomcat doesn't actually ever call x = new BasicDataSource(...). To reiterate, my original issue is that I'm trying to understand whether or not TC *always* pools container-managed DataSources. That's a simple No. And there are valid use-cases where you don't want them pooled, although those are fairly esoteric. I wonder where my original post in this thread, which had all this information, went ;) Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are all TC-managed DataSources pooled?
Thanks Yoav. I see your original reply in the archive now, but I never got it via email. Strange. I do occasionally get notifications from ezmlm that my mailbox has been bouncing mails, but haven't had one of those for a while. I think the bouncing is due to false positives at my ISP spamfilter, as my mailbox has plenty of free space. So I'm going to submit an enhacement suggestion for the docs (5.0.x/5.5.x), as they imply that DBCP is always used for datasources. a couple more follow up Qs to clarify if you wouldn't mind: there are valid use-cases where you don't want them pooled, although those are fairly esoteric. Is this a case where I might use org.apache.commons.dbcp.BasicDataSource? As far as I understand it, that class is DBCP's standard non-pooled DataSource...? And, are the following valid ways to tell whether a DataSource or Connection has come from a pooled or non-pooled source? : if (conn instanceof javax.sql.PooledConnection) if (dataSource instanceof javax.sql.ConnectionPoolDataSource) I ask this because, whether I specify the factory class or not, the DataSource/Connection classes I get back are: datasource class = org.apache.commons.dbcp.BasicDataSource connection class = org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper which both fail the tests above, despite the latter's name implying poolability Maybe BasicDataSourceFactory does not produce a pooled DataSource(?), but this seems odd given that it is the recommended class to use in the MySql DBCP example in the docs here: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-how to.html And I can't see another class within DBCP that looks like the pooled datasource factory that I need to specify in my factory param...? -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday 11 November 2004 13:24 To: Tomcat Users List Subject: RE: Are all TC-managed DataSources pooled? Hi, I already answered this... Maybe my post was lost. I had a search through the J2EE spec. It does not appear to me to _require_ that DataSources are provided in a pooled implementation. It seems to be preferred. For example: You're right. Containers are required to support binding of a DataSource, but it doesn't have to be pooling. Most implementations give the user the choice, as does Tomcat. You can use DBCP in non-pooling ways (set maxActive to infinite), or use any DataSource implementation whether it supports pooling or not. Also there are the other Qs in my last post - including, what is the effect of including this: parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter That's effectively required for Tomcat to be able to create org.apache.commons.dbcp.BasicDataSource instances. The general JNDI approach in Tomcat is factory-based (this has since been replicated in many other server implementations), where the provider impl includes a factory, so Tomcat doesn't actually ever call x = new BasicDataSource(...). To reiterate, my original issue is that I'm trying to understand whether or not TC *always* pools container-managed DataSources. That's a simple No. And there are valid use-cases where you don't want them pooled, although those are fairly esoteric. I wonder where my original post in this thread, which had all this information, went ;) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are all TC-managed DataSources pooled?
Hi, So I'm going to submit an enhacement suggestion for the docs (5.0.x/5.5.x), as they imply that DBCP is always used for datasources. The docs give a DBCP example. If someone needs to be told another implementation can be plugged in, they not competent enough to be doing the plugging. But if you feel like clarifying ad-nauseam, feel free to submit doc patches as always. Is this a case where I might use org.apache.commons.dbcp.BasicDataSource? As far as I understand it, that class is DBCP's standard non-pooled DataSource...? Your understanding is wrong. BasicDataSource can be pooled or not, depending on how you configure it. And, are the following valid ways to tell whether a DataSource or Connection has come from a pooled or non-pooled source? : if (conn instanceof javax.sql.PooledConnection) if (dataSource instanceof javax.sql.ConnectionPoolDataSource) They're not conclusive ways. There might not be a conclusive *portable* way to tell. It depends on the pooling implementation. which both fail the tests above, despite the latter's name implying poolability Implications are just that, nothing concrete. Your tests are incorrect. Maybe BasicDataSourceFactory does not produce a pooled DataSource(?), but It produces a BasicDataSource, which may or may not be pooling. And I can't see another class within DBCP that looks like the pooled datasource factory that I need to specify in my factory param...? You need to read the JNDI (not just JDBC DataSource) doc again, and/or make sure you understand the concept of a factory class. The latter is not in the scope of Tomcat documentation. DBCP provides numerous factories, all of which can produce pooling AND non-pooling data sources, and the pools provided have different strategies. Not all resource pooling is the same. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are all TC-managed DataSources pooled?
OK thanks, some useful points. I'll do some more reading. :)
So I'm going to submit an enhacement suggestion for the docs
(5.0.x/5.5.x),
as they imply that DBCP is always used for datasources.
The docs give a DBCP example. If someone needs to be told another
implementation can be plugged in, they not competent enough
to be doing the plugging.
That's not the point I'm making. The jndi-resource-how-to ('JDBC Data
Sources', '0. Introduction')
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.html#JD
BC%20Data%20Sources
says, Many web applications need to access a database via a JDBC driver
The J2EE Platform Specification requires J2EE Application Servers to make
available a DataSource implementation (that is, a connection pool for JDBC
connections) for this purpose. Surely this is not correct given what we've
already said, i.e. the connection pool is not required?
Your understanding is wrong. BasicDataSource can be pooled or not,
depending on how you configure it.
OK. By configure are you just meaning the maxActive, maxIdle params, or
there more to it than that, in determining whether it's pooled or not? e.g.
the choice of factory class perhaps?
Thanks :)
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Thursday 11 November 2004 14:51
To: Tomcat Users List
Subject: RE: Are all TC-managed DataSources pooled?
Hi,
So I'm going to submit an enhacement suggestion for the docs
(5.0.x/5.5.x),
as they imply that DBCP is always used for datasources.
The docs give a DBCP example. If someone needs to be told another
implementation can be plugged in, they not competent enough
to be doing
the plugging. But if you feel like clarifying ad-nauseam,
feel free to
submit doc patches as always.
Is this a case where I might use
org.apache.commons.dbcp.BasicDataSource?
As far as I understand it, that class is DBCP's standard non-pooled
DataSource...?
Your understanding is wrong. BasicDataSource can be pooled or not,
depending on how you configure it.
And, are the following valid ways to tell whether a DataSource or
Connection
has come from a pooled or non-pooled source? :
if (conn instanceof javax.sql.PooledConnection)
if (dataSource instanceof javax.sql.ConnectionPoolDataSource)
They're not conclusive ways. There might not be a conclusive
*portable*
way to tell. It depends on the pooling implementation.
which both fail the tests above, despite the latter's name implying
poolability
Implications are just that, nothing concrete. Your tests are
incorrect.
Maybe BasicDataSourceFactory does not produce a pooled DataSource(?),
but
It produces a BasicDataSource, which may or may not be pooling.
And I can't see another class within DBCP that looks like the pooled
datasource factory that I need to specify in my factory param...?
You need to read the JNDI (not just JDBC DataSource) doc again, and/or
make sure you understand the concept of a factory class. The
latter is
not in the scope of Tomcat documentation.
DBCP provides numerous factories, all of which can produce pooling AND
non-pooling data sources, and the pools provided have different
strategies. Not all resource pooling is the same.
Yoav
This e-mail, including any attachments, is a confidential
business communication, and may contain information that is
confidential, proprietary and/or privileged. This e-mail is
intended only for the individual(s) to whom it is addressed,
and may not be saved, copied, printed, disclosed or used by
anyone else. If you are not the(an) intended recipient,
please immediately delete this e-mail from your computer
system and notify the sender. Thank you.
-
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]
RE: Are all TC-managed DataSources pooled?
Hi, The J2EE Platform Specification requires J2EE Application Servers to make available a DataSource implementation (that is, a connection pool for JDBC connections) for this purpose. Surely this is not correct given what we've already said, i.e. the connection pool is not required? A DataSource implementation is required. It may or may not pooling, but you'd be hard-pressed to find one that doesn't support pooling. OK. By configure are you just meaning the maxActive, maxIdle params, or Yeah, its configuration parameters. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are all TC-managed DataSources pooled?
No interest in my original post so I'll rephrase. Is every container-managed DataSource configured in TC (e.g. via server.xml / context.xml) automatically made pooled using commons pooling? Or can ordinary non-pooled connections be created too using this mechanism? -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Tuesday 09 November 2004 00:45 To: 'Tomcat Users List' Subject: Are all TC-managed DataSources pooled? The docs under 'JDBC Data Sources' at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources -howto.html say, The J2EE Platform Specification requires J2EE Application Servers to make available a DataSource implementation (that is, a connection pool for JDBC connections). Now, I'm *not* criticising the docs, I'm seeking clarification. I'm not sure whether this is saying that a JDBC DataSource has to be pooled? Or is instead saying that J2EE requires pooled JDBC connections, or maybe that J2EE requires connections via a DataSource? I didn't think that DataSources had to be pooled, based on what is says here: http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/DataSource.html This might sound like nit picking, but the answer to this will help me help someone else on another thread. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are all TC-managed DataSources pooled?
For JDBC if it's not pooled in a container, it would be of little use to any application. Specifically the tomcat docs do say that connection pool is provided right here : http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jndi-datasource-examples-howto.html#Database%20Connection%20Pool%20(DBCP)%20Configurations Just set it up according to the docs(with changes for your jdbc driver) and you're good to go. On Wed, 10 Nov 2004 23:30:08 -, Steve Kirk [EMAIL PROTECTED] wrote: No interest in my original post so I'll rephrase. Is every container-managed DataSource configured in TC (e.g. via server.xml / context.xml) automatically made pooled using commons pooling? Or can ordinary non-pooled connections be created too using this mechanism? -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Tuesday 09 November 2004 00:45 To: 'Tomcat Users List' Subject: Are all TC-managed DataSources pooled? The docs under 'JDBC Data Sources' at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources -howto.html say, The J2EE Platform Specification requires J2EE Application Servers to make available a DataSource implementation (that is, a connection pool for JDBC connections). Now, I'm *not* criticising the docs, I'm seeking clarification. I'm not sure whether this is saying that a JDBC DataSource has to be pooled? Or is instead saying that J2EE requires pooled JDBC connections, or maybe that J2EE requires connections via a DataSource? I didn't think that DataSources had to be pooled, based on what is says here: http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/DataSource.html This might sound like nit picking, but the answer to this will help me help someone else on another thread. Thanks. - 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]
Re: Are all TC-managed DataSources pooled?
Is every container-managed DataSource configured in TC (e.g. via server.xml / context.xml) automatically made pooled using commons pooling? Yes. No additional code is needed (i.e. TC takes care of the pool.) Or can ordinary non-pooled connections be created too using this mechanism? No, as it would not be compliant. It might be possible to create a pool of one connection, but it would still be handled as a pool. To answer your original questions: Now, I'm *not* criticising the docs, I'm seeking clarification. I'm not sure whether this is saying that a JDBC DataSource has to be pooled? Or is instead saying that J2EE requires pooled JDBC connections, or maybe that J2EE requires connections via a DataSource? To meet the J2EE requirement the DataSource method must be made avalible in a pooled configuration. I didn't think that DataSources had to be pooled, based on what is says here: http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/DataSource.html This is only the API for the language. The language may be able to do many things that are not compliant with the J2EE standard reguarding the server. Think about if you were writing a stand alone desktop app and had it talking to a datasource. The J2EE requirements for the server are of no interest and don't apply. This might sound like nit picking, but the answer to this will help me help someone else on another thread. Thanks. Hope they get the picture. Doug www.parsonstechnical.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are all TC-managed DataSources pooled?
Hi, No, the DataSources are not required to be pooled. J2EE only requires that a container provide a DataSource binding. How that DataSource is implemented is up to the container (which usually defers to the server admin, as we do). You can use pooling or non-pooling DataSources, XA DataSources, and other varieties as you see fit. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, November 08, 2004 7:45 PM To: 'Tomcat Users List' Subject: Are all TC-managed DataSources pooled? The docs under 'JDBC Data Sources' at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.ht ml say, The J2EE Platform Specification requires J2EE Application Servers to make available a DataSource implementation (that is, a connection pool for JDBC connections). Now, I'm *not* criticising the docs, I'm seeking clarification. I'm not sure whether this is saying that a JDBC DataSource has to be pooled? Or is instead saying that J2EE requires pooled JDBC connections, or maybe that J2EE requires connections via a DataSource? I didn't think that DataSources had to be pooled, based on what is says here: http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/DataSource.html This might sound like nit picking, but the answer to this will help me help someone else on another thread. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
