You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2013/12/20 07:23:08 UTC
Re: [jira] [Commented] (CAY-1864) Process threads waiting for an available DB connection in the order they came in
(taking this to dev)
On Dec 20, 2013, at 1:46 AM, John Huss (JIRA) <ji...@apache.org> wrote:
> John Huss commented on CAY-1864:
> --------------------------------
>
> I've got tomcat-jdbc in my project now, so I'm going to try that rather than continue improving PoolManager. One issue I had with integrating tomcat-jdbc is that if you configure your data source using cayenne's properties (like cayenne.jdbc.driver) then it switches your DataSourceFactory to PropertyDataSourceFactory even if you have entered a custom factory in your cayenne.xml file. I'd suggest that cayenne should only override the factory if it is the default value - XMLPoolingDataSourceFactory.
>
> As a workaround I renamed my properties (which I am still using). But it would be nicer to have the same property names and be able to switch connection pool implementations merely by changing the DataSourceFactory.
This is by design. The actual DataSourceFactory, as defined in the ServerModule is DelegatingDataSourceFactory:
binder.bind(DataSourceFactory.class).to(DelegatingDataSourceFactory.class);
The point of which is that the app (or even a deployer) should have an easy way to override a factory name specified in XML.
cayenne.jdbc.* properties are of course intended for DelegatingDataSourceFactory/PropertyDataSourceFactory. Are you using these properties for something else?
Andrus
Re: [jira] [Commented] (CAY-1864) Process threads waiting for an
available DB connection in the order they came in
Posted by John Huss <jo...@gmail.com>.
On Fri, Dec 20, 2013 at 9:59 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
> > I'd like to use the same property names to configure my own
> > DataSourceFactory, which is basically identical to
> > PropertyDataSourceFactory, but uses the tomcat-jdbc connection pooling.
>
> Got it.
>
> > The use of properties to configure the data source is somewhat orthogonal
> > to the choice connection pool implementation.
>
>
> I didn’t think of it this way when I designed it. Consider the following
> scenario. Most of my projects are using JNDI factory. At the same time when
> I am running them from Eclipse, using Jetty launcher [1], I don’t have JNDI
> environment. So I would simply specify my local DB properties. So the idea
> is to overtake whatever factory is specified, and just connect to DB
> directly.
>
> So yeah, using a different prefix for your factory properties is probably
> the way to go.
Yes
> Or alternatively you can bind your factory instead of
> PropertyDataSourceFactory in DI, which was also a scenario I considered
> during the initial design.
>
The problem with this is that it requires using properties for every
connection, which I am not doing. I have three data nodes and only one is
configured via properties.
>
> Andrus
>
> [1] https://github.com/andrus/jetty-launcher
>
> On Dec 20, 2013, at 6:48 PM, John Huss <jo...@gmail.com> wrote:
>
> > On Fri, Dec 20, 2013 at 12:23 AM, Andrus Adamchik <
> andrus@objectstyle.org>wrote:
> >
> >> (taking this to dev)
> >>
> >> On Dec 20, 2013, at 1:46 AM, John Huss (JIRA) <ji...@apache.org> wrote:
> >>
> >>> John Huss commented on CAY-1864:
> >>> --------------------------------
> >>>
> >>> I've got tomcat-jdbc in my project now, so I'm going to try that rather
> >> than continue improving PoolManager. One issue I had with integrating
> >> tomcat-jdbc is that if you configure your data source using cayenne's
> >> properties (like cayenne.jdbc.driver) then it switches your
> >> DataSourceFactory to PropertyDataSourceFactory even if you have entered
> a
> >> custom factory in your cayenne.xml file. I'd suggest that cayenne
> should
> >> only override the factory if it is the default value -
> >> XMLPoolingDataSourceFactory.
> >>>
> >>> As a workaround I renamed my properties (which I am still using). But
> >> it would be nicer to have the same property names and be able to switch
> >> connection pool implementations merely by changing the
> DataSourceFactory.
> >>
> >> This is by design. The actual DataSourceFactory, as defined in the
> >> ServerModule is DelegatingDataSourceFactory:
> >>
> >>
> >>
> binder.bind(DataSourceFactory.class).to(DelegatingDataSourceFactory.class);
> >>
> >> The point of which is that the app (or even a deployer) should have an
> >> easy way to override a factory name specified in XML.
> >>
> >> cayenne.jdbc.* properties are of course intended for
> >> DelegatingDataSourceFactory/PropertyDataSourceFactory. Are you using
> these
> >> properties for something else?
> >>
> >
> > I'd like to use the same property names to configure my own
> > DataSourceFactory, which is basically identical to
> > PropertyDataSourceFactory, but uses the tomcat-jdbc connection pooling.
> > The use of properties to configure the data source is somewhat orthogonal
> > to the choice connection pool implementation.
> >
> > Since DelegatingDataSourceFactory is only meant to switch between the
> > Property or XML factory then it should only do that, so I'd like to add
> > this:
> >
> > protected boolean shouldConfigureDataSourceFromProperties(
> > DataNodeDescriptor nodeDescriptor) {
> >
> > if
> >
> (!(XMLPoolingDataSourceFactory.class.getName().equals(nodeDescriptor.getDataSourceFactoryType())
> > ||
> > PropertyDataSourceFactory
> > .class.getName().equals(nodeDescriptor.getDataSourceFactoryType()))) {
> > return false;
> > }
> > ...
> > }
> >
> >
> >>
> >> Andrus
> >>
> >>
> >>
>
>
Re: [jira] [Commented] (CAY-1864) Process threads waiting for an available DB connection in the order they came in
Posted by Andrus Adamchik <an...@objectstyle.org>.
> I'd like to use the same property names to configure my own
> DataSourceFactory, which is basically identical to
> PropertyDataSourceFactory, but uses the tomcat-jdbc connection pooling.
Got it.
> The use of properties to configure the data source is somewhat orthogonal
> to the choice connection pool implementation.
I didn’t think of it this way when I designed it. Consider the following scenario. Most of my projects are using JNDI factory. At the same time when I am running them from Eclipse, using Jetty launcher [1], I don’t have JNDI environment. So I would simply specify my local DB properties. So the idea is to overtake whatever factory is specified, and just connect to DB directly.
So yeah, using a different prefix for your factory properties is probably the way to go. Or alternatively you can bind your factory instead of PropertyDataSourceFactory in DI, which was also a scenario I considered during the initial design.
Andrus
[1] https://github.com/andrus/jetty-launcher
On Dec 20, 2013, at 6:48 PM, John Huss <jo...@gmail.com> wrote:
> On Fri, Dec 20, 2013 at 12:23 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
>
>> (taking this to dev)
>>
>> On Dec 20, 2013, at 1:46 AM, John Huss (JIRA) <ji...@apache.org> wrote:
>>
>>> John Huss commented on CAY-1864:
>>> --------------------------------
>>>
>>> I've got tomcat-jdbc in my project now, so I'm going to try that rather
>> than continue improving PoolManager. One issue I had with integrating
>> tomcat-jdbc is that if you configure your data source using cayenne's
>> properties (like cayenne.jdbc.driver) then it switches your
>> DataSourceFactory to PropertyDataSourceFactory even if you have entered a
>> custom factory in your cayenne.xml file. I'd suggest that cayenne should
>> only override the factory if it is the default value -
>> XMLPoolingDataSourceFactory.
>>>
>>> As a workaround I renamed my properties (which I am still using). But
>> it would be nicer to have the same property names and be able to switch
>> connection pool implementations merely by changing the DataSourceFactory.
>>
>> This is by design. The actual DataSourceFactory, as defined in the
>> ServerModule is DelegatingDataSourceFactory:
>>
>>
>> binder.bind(DataSourceFactory.class).to(DelegatingDataSourceFactory.class);
>>
>> The point of which is that the app (or even a deployer) should have an
>> easy way to override a factory name specified in XML.
>>
>> cayenne.jdbc.* properties are of course intended for
>> DelegatingDataSourceFactory/PropertyDataSourceFactory. Are you using these
>> properties for something else?
>>
>
> I'd like to use the same property names to configure my own
> DataSourceFactory, which is basically identical to
> PropertyDataSourceFactory, but uses the tomcat-jdbc connection pooling.
> The use of properties to configure the data source is somewhat orthogonal
> to the choice connection pool implementation.
>
> Since DelegatingDataSourceFactory is only meant to switch between the
> Property or XML factory then it should only do that, so I'd like to add
> this:
>
> protected boolean shouldConfigureDataSourceFromProperties(
> DataNodeDescriptor nodeDescriptor) {
>
> if
> (!(XMLPoolingDataSourceFactory.class.getName().equals(nodeDescriptor.getDataSourceFactoryType())
> ||
> PropertyDataSourceFactory
> .class.getName().equals(nodeDescriptor.getDataSourceFactoryType()))) {
> return false;
> }
> ...
> }
>
>
>>
>> Andrus
>>
>>
>>
Re: [jira] [Commented] (CAY-1864) Process threads waiting for an
available DB connection in the order they came in
Posted by John Huss <jo...@gmail.com>.
On Fri, Dec 20, 2013 at 12:23 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
> (taking this to dev)
>
> On Dec 20, 2013, at 1:46 AM, John Huss (JIRA) <ji...@apache.org> wrote:
>
> > John Huss commented on CAY-1864:
> > --------------------------------
> >
> > I've got tomcat-jdbc in my project now, so I'm going to try that rather
> than continue improving PoolManager. One issue I had with integrating
> tomcat-jdbc is that if you configure your data source using cayenne's
> properties (like cayenne.jdbc.driver) then it switches your
> DataSourceFactory to PropertyDataSourceFactory even if you have entered a
> custom factory in your cayenne.xml file. I'd suggest that cayenne should
> only override the factory if it is the default value -
> XMLPoolingDataSourceFactory.
> >
> > As a workaround I renamed my properties (which I am still using). But
> it would be nicer to have the same property names and be able to switch
> connection pool implementations merely by changing the DataSourceFactory.
>
> This is by design. The actual DataSourceFactory, as defined in the
> ServerModule is DelegatingDataSourceFactory:
>
>
> binder.bind(DataSourceFactory.class).to(DelegatingDataSourceFactory.class);
>
> The point of which is that the app (or even a deployer) should have an
> easy way to override a factory name specified in XML.
>
> cayenne.jdbc.* properties are of course intended for
> DelegatingDataSourceFactory/PropertyDataSourceFactory. Are you using these
> properties for something else?
>
I'd like to use the same property names to configure my own
DataSourceFactory, which is basically identical to
PropertyDataSourceFactory, but uses the tomcat-jdbc connection pooling.
The use of properties to configure the data source is somewhat orthogonal
to the choice connection pool implementation.
Since DelegatingDataSourceFactory is only meant to switch between the
Property or XML factory then it should only do that, so I'd like to add
this:
protected boolean shouldConfigureDataSourceFromProperties(
DataNodeDescriptor nodeDescriptor) {
if
(!(XMLPoolingDataSourceFactory.class.getName().equals(nodeDescriptor.getDataSourceFactoryType())
||
PropertyDataSourceFactory
.class.getName().equals(nodeDescriptor.getDataSourceFactoryType()))) {
return false;
}
...
}
>
> Andrus
>
>
>