[xwiki-devs] [VOTE] Change our default Connection Pooling framework for Hibernate to BoneCP
Hi devs, I was trying to make XEM work with HSQLDB and... I have succeeded :) The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine. I've googled around and found that there are lots of people complaining about DBCP. I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html So here's what I'd like to propose: * We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP: <property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property> <property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. WDYT? Here's my +1 for this action plan. Thanks -Vincent
+1 to do this in 4.3 Thanks, Marius On Mon, Sep 24, 2012 at 6:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Note that it seems I also have some problems with BoneCP (not as many as with DBCP but still similar issues) which seem to indicate the problem might be elsewhere with HSQLDB support… I think this email is still valid even if it means I need to continue digging to fix the HSQLDB issue… ;) Thanks -Vincent On Sep 24, 2012, at 5:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks -Vincent
+1 for 4.3 On Mon, Sep 24, 2012 at 5:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue. But having looked into this I'm a bit worried about the current XEM implementation. I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath? What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes? +1 for your action plan. Best Regards, /Andreas
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation.
You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath?
The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features. Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason.
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining
about DBCP.
I've googled for what connection pooling library to use and I've found
that most people are recommending BoneCP (http://jolbox.com/).
See: *
http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library...
* http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year. So, currently, I am -1.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
See below. On Sep 25, 2012, at 10:48 AM, Denis Gervalle <[email protected]> wrote:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation.
You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath?
The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason.
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining
about DBCP.
I've googled for what connection pooling library to use and I've found
that most people are recommending BoneCP (http://jolbox.com/).
See: *
http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library...
* http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter.
I understand. You should also consider that Apache DBCP is well known for: * being slow * being full of bugs * having a stalled develoment At least that's what I keep seeing mentioned in all my google everywhere. I think you shouldn't think Apache == Good. At least not for Commons. Commons libs can be very small and maintained by very few people. If you check http://commons.apache.org/dbcp/team-list.html you'll see several committers. But if you check http://svnsearch.org/svnsearch/repos/ASF/search?view=plot&path=%2Fcommons%2F... you'll see that only 2 committers have been active since 2009. You should also note that Tomcat 7 has implemented its own connection pooling thus dropping DBCP even though they're both in apache land… you should ask why. I don't know the internal story but here's what they say: http://stackoverflow.com/questions/520585/connection-pooling-options-with-jd... Thanks -Vincent PS: I don't disagree with your analysis but we shouldn't be too fearful either of making discoveries/changes. Provided we can control them and revert easily it's not a bad thing to discover new stuff. PPS: BoneCP could not be the best choice. Maybe C3P0 is better now or maybe the new Tomcat Connection Pool is better. PPPS: In any case I'm not going to make any change till I get to the bottom of this issue with HSQLDB in virtual mode….
From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
On Tue, Sep 25, 2012 at 11:24 AM, Vincent Massol <[email protected]> wrote:
See below.
On Sep 25, 2012, at 10:48 AM, Denis Gervalle <[email protected]> wrote:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation.
You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath?
The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason.
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining
about DBCP.
I've googled for what connection pooling library to use and I've found
that most people are recommending BoneCP (http://jolbox.com/).
See: *
http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library...
* http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ *
http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we
shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see
http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property
name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still
work
* New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter.
I understand. You should also consider that Apache DBCP is well known for: * being slow * being full of bugs * having a stalled development
At least that's what I keep seeing mentioned in all my google everywhere.
Sure, I have never said that DBCP is perfect. We are not discussing about choosing it, we are currently using it and unless you express other real concerns than hypothetical performance improvement, I would not change it for BoneCP. If we were starting from scratch, the comparison of those library would be different. I found BoneCP really appealing in regards to technical matters, but I do not see it as a well contributed project, and its "owner" seems to have other concerns now.
I think you shouldn't think Apache == Good. At least not for Commons. Commons libs can be very small and maintained by very few people.
If you check http://commons.apache.org/dbcp/team-list.html you'll see several committers. But if you check http://svnsearch.org/svnsearch/repos/ASF/search?view=plot&path=%2Fcommons%2Fproper%2Fdbcp&plotsort=commitsyou'll see that only 2 committers have been active since 2009.
Do not make me said what I have not. I think Apache projects get better reputations in regards to business users than a standalone project. There is also more chance to see a apache project taken over than a standalone project. But I am not a so big fan of Apache.
You should also note that Tomcat 7 has implemented its own connection pooling thus dropping DBCP even though they're both in apache land… you should ask why. I don't know the internal story but here's what they say:
http://stackoverflow.com/questions/520585/connection-pooling-options-with-jd...
Again, I am not against changing if we have real value for that change. Currently the value of BoneCP is not worst the risk incurred by its lack of maintenance. Improve the balance, and I will reconsider my vote.
Thanks -Vincent
PS: I don't disagree with your analysis but we shouldn't be too fearful either of making discoveries/changes. Provided we can control them and revert easily it's not a bad thing to discover new stuff.
PPS: BoneCP could not be the best choice. Maybe C3P0 is better now or maybe the new Tomcat Connection Pool is better.
PPPS: In any case I'm not going to make any change till I get to the bottom of this issue with HSQLDB in virtual mode….
PS: I think we are agreeing :)
From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation.
You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath?
The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason.
Thank's for your reply. Maybe I've got a correct impression of the current state of affairs. I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy: Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context. For instance, templates could be prepared for entity mappings like so: <class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}"> And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed. But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards? Best regards, /Andreas
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining about DBCP. I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. WDYT?
Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html -Vincent On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation.
You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath?
The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason.
Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining about DBCP. I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. WDYT?
Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2012-09-25 12:12, Vincent Massol skrev:
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
That looks useful, but the database or schema seems to be fixed per session. Do we not need to access entities from different wikis within the same session? /Andreas
-Vincent
On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation. You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath? The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason. Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining about DBCP. I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. WDYT?
Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Sep 25, 2012 at 12:36 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 12:12, Vincent Massol skrev:
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
That looks useful, but the database or schema seems to be fixed per session. Do we not need to access entities from different wikis within the same session?
We do. If it's really strongly associated to the session we can't use that.
/Andreas
-Vincent
On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation. You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath? The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason. Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining about DBCP. I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. WDYT?
Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Sep 25, 2012 at 12:47 PM, Thomas Mortagne <[email protected]
wrote:
On Tue, Sep 25, 2012 at 12:36 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 12:12, Vincent Massol skrev:
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
That looks useful, but the database or schema seems to be fixed per session. Do we not need to access entities from different wikis within the same session?
We do. If it's really strongly associated to the session we can't use that.
Note that currently, we never do so, and this is a limitation that I do not expect hibernate to remove. You may well create multiple session, but I doubt you will reach soon a state where hibernate support sessions across databases. That said, I do not see any real benefit to build a different solution than the current one until we update to Hibernate4. In H4, it will be easy to use the multi-tenant implementation, even with the old model. It will provide some benefit for mapping, but will probably not improve the pool issue discussed here.
/Andreas
-Vincent
On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]>
wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]>
wrote:
2012-09-24 17:26, Vincent Massol skrev: > Hi devs, > > I was trying to make XEM work with HSQLDB and... I have succeeded :) > > The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes
calls to
fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation. You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath? The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason. Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
> I've googled around and found that there are lots of people complaining about DBCP. > I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). > See: > *
http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library...
> * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ > *
http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
> The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). > The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html > So here's what I'd like to propose: > > * We move DBCPConnectionProvider to a legacy module > * We bundle the bonecp jar by default > * We configure our hibernate.cfg.xml by default to use boneCP: > > <property name="bonecp.idleMaxAge">240</property> > <property name="bonecp.idleConnectionTestPeriod">60</property> > <property name="bonecp.partitionCount">3</property> > <property name="bonecp.acquireIncrement">10</property> > <property name="bonecp.maxConnectionsPerPartition">60</property> > <property name="bonecp.minConnectionsPerPartition">20</property> > <property name="bonecp.statementsCacheSize">50</property> > <property name="bonecp.releaseHelperThreads">3</property> > > <property
name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
> What this means: > * Existing users of XWiki will not have to change anything, it'll still work > * New users will use bonecp without knowing > * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file > I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. > WDYT? > > Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
> Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
2012-09-25 15:27, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 12:47 PM, Thomas Mortagne <[email protected]
wrote: On Tue, Sep 25, 2012 at 12:36 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 12:12, Vincent Massol skrev:
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html That looks useful, but the database or schema seems to be fixed per session. Do we not need to access entities from different wikis within the same session? We do. If it's really strongly associated to the session we can't use that.
Note that currently, we never do so, and this is a limitation that I do not expect hibernate to remove. You may well create multiple session, but I doubt you will reach soon a state where hibernate support sessions across databases.
So, are you saying that the implementation idea I mentioned will not work? Here is again what I wrote: Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context. For instance, templates could be prepared for entity mappings like so: <class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}"> And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed. Best Regards, /Andreas
That said, I do not see any real benefit to build a different solution than the current one until we update to Hibernate4. In H4, it will be easy to use the multi-tenant implementation, even with the old model. It will provide some benefit for mapping, but will probably not improve the pool issue discussed here.
/Andreas
-Vincent
On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]>
wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]> wrote: > 2012-09-24 17:26, Vincent Massol skrev: >> Hi devs, >> >> I was trying to make XEM work with HSQLDB and... I have succeeded :) >> >> The only problem I have is that DBCP doesn't seem to work with > Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to > fail afterwards. In any case if I configure Hibernate to not use DBCP all > work just fine. > > Funny coincidence! I was just trying to get it to work with > PostgreSQL. It mostly works, as already commented on the Jira issue. > The only thing that seems to work unreliably is the initial template > creation. It seems likely that it is the same issue. > > But having looked into this I'm a bit worried about the current XEM > implementation. You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
> I'm not an expert on Hibernate, but to me it seems that > entities are expected to be bound to specific tables at initialization > time. So I'm wondering, does Hibernate really support changing the > mappings by switching databases or schemas underneath? The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason. Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
> What prevents it > from generating prepared queries for accessing the entities, which will > be resolved against the initial database/schema, and continue to use > these even after the database or schema changes? > Our config prevent using prepared statements on the DB server.
> +1 for your action plan. > > Best Regards, > > /Andreas > >> I've googled around and found that there are lots of people complaining > about DBCP. >> I've googled for what connection pooling library to use and I've found > that most people are recommending BoneCP (http://jolbox.com/). >> See: >> * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... >> * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ >> * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... >> The other thing is that we currently have some 300 line of code that we > shouldn't have at all and that we need in XWiki just for handling DBCP (see > com.xpn.xwiki.store.DBCPConnectionProvider). >> The pro of BoneCP is that it seems to be the fastest, see > http://jolbox.com/benchmarks.html >> So here's what I'd like to propose: >> >> * We move DBCPConnectionProvider to a legacy module >> * We bundle the bonecp jar by default >> * We configure our hibernate.cfg.xml by default to use boneCP: >> >> <property name="bonecp.idleMaxAge">240</property> >> <property name="bonecp.idleConnectionTestPeriod">60</property> >> <property name="bonecp.partitionCount">3</property> >> <property name="bonecp.acquireIncrement">10</property> >> <property name="bonecp.maxConnectionsPerPartition">60</property> >> <property name="bonecp.minConnectionsPerPartition">20</property> >> <property name="bonecp.statementsCacheSize">50</property> >> <property name="bonecp.releaseHelperThreads">3</property> >> >> <property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> >> What this means: >> * Existing users of XWiki will not have to change anything, it'll still > work >> * New users will use bonecp without knowing >> * Existing users can migrate to bonecp just by changing one line in > their hibernate.cfg.xml file >> I'd love to do this for 4.3 but we're already quite advanced in the 4.x > cycle. That said it's just a one line change in hibernate.cfg.xml in case > of problem to go back to DBCP so we could do this for 4.3 which leaves us > 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll > always be able to release a 4.5.1 that has this one line change to go back > to DBCP. >> WDYT? >> >> Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
>> Thanks >> -Vincent >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Sep 25, 2012 at 3:27 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Sep 25, 2012 at 12:47 PM, Thomas Mortagne <[email protected]
wrote:
On Tue, Sep 25, 2012 at 12:36 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 12:12, Vincent Massol skrev:
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
That looks useful, but the database or schema seems to be fixed per session. Do we not need to access entities from different wikis within the same session?
We do. If it's really strongly associated to the session we can't use that.
Note that currently, we never do so, and this is a limitation that I do not expect hibernate to remove. You may well create multiple session, but I doubt you will reach soon a state where hibernate support sessions across databases.
Actually I understood HTTP session. About connection session the only use case for it is object class woming from another wiki but this is an official limitation right now.
That said, I do not see any real benefit to build a different solution than the current one until we update to Hibernate4. In H4, it will be easy to use the multi-tenant implementation, even with the old model. It will provide some benefit for mapping, but will probably not improve the pool issue discussed here.
/Andreas
-Vincent
On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]>
wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]>
wrote:
> 2012-09-24 17:26, Vincent Massol skrev: >> Hi devs, >> >> I was trying to make XEM work with HSQLDB and... I have succeeded :) >> >> The only problem I have is that DBCP doesn't seem to work with > Hibernate. For some weird reasons when we do a SET SCHEMA it makes
calls to
> fail afterwards. In any case if I configure Hibernate to not use DBCP all > work just fine. > > Funny coincidence! I was just trying to get it to work with > PostgreSQL. It mostly works, as already commented on the Jira issue. > The only thing that seems to work unreliably is the initial template > creation. It seems likely that it is the same issue. > > But having looked into this I'm a bit worried about the current XEM > implementation. You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
> I'm not an expert on Hibernate, but to me it seems that > entities are expected to be bound to specific tables at initialization > time. So I'm wondering, does Hibernate really support changing the > mappings by switching databases or schemas underneath? The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason. Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
> What prevents it > from generating prepared queries for accessing the entities, which will > be resolved against the initial database/schema, and continue to use > these even after the database or schema changes? > Our config prevent using prepared statements on the DB server.
> +1 for your action plan. > > Best Regards, > > /Andreas > >> I've googled around and found that there are lots of people complaining > about DBCP. >> I've googled for what connection pooling library to use and I've found > that most people are recommending BoneCP (http://jolbox.com/). >> See: >> * > http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... >> * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ >> * > http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon... >> The other thing is that we currently have some 300 line of code that we > shouldn't have at all and that we need in XWiki just for handling DBCP (see > com.xpn.xwiki.store.DBCPConnectionProvider). >> The pro of BoneCP is that it seems to be the fastest, see > http://jolbox.com/benchmarks.html >> So here's what I'd like to propose: >> >> * We move DBCPConnectionProvider to a legacy module >> * We bundle the bonecp jar by default >> * We configure our hibernate.cfg.xml by default to use boneCP: >> >> <property name="bonecp.idleMaxAge">240</property> >> <property name="bonecp.idleConnectionTestPeriod">60</property> >> <property name="bonecp.partitionCount">3</property> >> <property name="bonecp.acquireIncrement">10</property> >> <property name="bonecp.maxConnectionsPerPartition">60</property> >> <property name="bonecp.minConnectionsPerPartition">20</property> >> <property name="bonecp.statementsCacheSize">50</property> >> <property name="bonecp.releaseHelperThreads">3</property> >> >> <property > name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property> >> What this means: >> * Existing users of XWiki will not have to change anything, it'll still > work >> * New users will use bonecp without knowing >> * Existing users can migrate to bonecp just by changing one line in > their hibernate.cfg.xml file >> I'd love to do this for 4.3 but we're already quite advanced in the 4.x > cycle. That said it's just a one line change in hibernate.cfg.xml in case > of problem to go back to DBCP so we could do this for 4.3 which leaves us > 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll > always be able to release a 4.5.1 that has this one line change to go back > to DBCP. >> WDYT? >> >> Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
>> Thanks >> -Vincent >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 for 4.3 Since, as Vincent mentioned, we have the 4.3, 4.4 and 4.5 releases as backup, I personally don`t see any risk in trying out what seems to be the better library. If all it takes is a couple of lines in hibernate.cfg.xml to do the switch, I`d say go with it. I agree that we need to consider the long run, but, as far as I understand, there is nothing guaranteeing that DBCP will get better in useful time (though it is under the Apache umbrella, but people tend to stay away from it) as there is nothing guaranteeing that BoneCP will lose it's development support (though more and more people seem to be switching to it for its benefits). Thanks, Eduard P.S.: My above comments are not based on previous experience, but only on a quick analysis of this thread. On Tue, Sep 25, 2012 at 1:36 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 12:12, Vincent Massol skrev:
FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
That looks useful, but the database or schema seems to be fixed per session. Do we not need to access entities from different wikis within the same session?
/Andreas
-Vincent
On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <[email protected]> wrote:
2012-09-25 10:48, Denis Gervalle skrev:
On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <[email protected]>
wrote:
2012-09-24 17:26, Vincent Massol skrev:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes
calls to
fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
Funny coincidence! I was just trying to get it to work with PostgreSQL. It mostly works, as already commented on the Jira issue. The only thing that seems to work unreliably is the initial template creation. It seems likely that it is the same issue.
But having looked into this I'm a bit worried about the current XEM implementation. You should, we really do scary stuff to support multiple DB, and also dynamic mapping.
I'm not an expert on Hibernate, but to me it seems that entities are expected to be bound to specific tables at initialization time. So I'm wondering, does Hibernate really support changing the mappings by switching databases or schemas underneath? The tricks is that we do not really support multiple hibernate mapping. All accessed DBs use the same mapping. These are serious limitations in multi-wiki mode for mapping related features.
Hibernate does not even knows that we switch the DB under its feet. Even the pool provider is not aware. This is why we need to set the correct DB each time we open a session/transaction (always tight together), which means getting a connection from the pool. We do not support nested session/transaction, in particular to different DBs for the same reason. Thank's for your reply. Maybe I've got a correct impression of the current state of affairs.
I guess this issue will be addressed in the new model implementation, but I was thinking of this solution, which seems to be possible with a reasonably small effort and with full backwards compliancy:
Re-register the entity mappings for each wiki, adding a wiki-specific prefix to each entity name. Then let a custom EntityNameResolver add the prefix by taking the current database from the execution context.
For instance, templates could be prepared for entity mappings like so:
<class name="${entityNamePrefix}:com.xpn.xwiki.doc.XWikiDocument" table="xwikidoc" schema="${entitySchemaAttribute}">
And then the SessionFactory is rebuilt whenever a wiki is created or deleted. I'm a bit confused on how and when custom mappings are "injected", and there might be other things that I've missed.
But on the other hand, aren't there any frameworks that can do this? What about Hibernate Shards?
Best regards,
/Andreas
What prevents it from generating prepared queries for accessing the entities, which will be resolved against the initial database/schema, and continue to use these even after the database or schema changes?
Our config prevent using prepared statements on the DB server.
+1 for your action plan.
Best Regards,
/Andreas
I've googled around and found that there are lots of people complaining about DBCP. I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/). See: *
http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library...
* http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ *
http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider). The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property
name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP. WDYT?
Here's my +1 for this action plan. Unless BoneCP really provide proven improvements, and not only a potential performance increase, that will probably not be tremendous, I am not really in favor of changing a well-know Apache project for a project that as not really a great team of supporter. From the project info page, I see only one name. From the forum, there seems to be serious rumors that the project is no more supported by that guy since more than a year.
So, currently, I am -1.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
BTW a comparison between Tomcat DBCP and Apache Commons DBCP: http://stackoverflow.com/questions/520585/connection-pooling-options-with-jd... -Vincent On Sep 24, 2012, at 5:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks -Vincent
For the record here's what the Hibernate team said about why they removed DBCP support: https://forum.hibernate.org/viewtopic.php?f=1&t=947528&view=next This is referenced from this blog article: http://www.mkyong.com/hibernate/how-to-configure-dbcp-connection-pool-in-hib... -Vincent On Sep 24, 2012, at 5:26 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I was trying to make XEM work with HSQLDB and... I have succeeded :)
The only problem I have is that DBCP doesn't seem to work with Hibernate. For some weird reasons when we do a SET SCHEMA it makes calls to fail afterwards. In any case if I configure Hibernate to not use DBCP all work just fine.
I've googled around and found that there are lots of people complaining about DBCP.
I've googled for what connection pooling library to use and I've found that most people are recommending BoneCP (http://jolbox.com/).
See: * http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-library... * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ * http://stackoverflow.com/questions/8057110/java-database-connection-pool-bon...
The other thing is that we currently have some 300 line of code that we shouldn't have at all and that we need in XWiki just for handling DBCP (see com.xpn.xwiki.store.DBCPConnectionProvider).
The pro of BoneCP is that it seems to be the fastest, see http://jolbox.com/benchmarks.html
So here's what I'd like to propose:
* We move DBCPConnectionProvider to a legacy module * We bundle the bonecp jar by default * We configure our hibernate.cfg.xml by default to use boneCP:
<property name="bonecp.idleMaxAge">240</property> <property name="bonecp.idleConnectionTestPeriod">60</property> <property name="bonecp.partitionCount">3</property> <property name="bonecp.acquireIncrement">10</property> <property name="bonecp.maxConnectionsPerPartition">60</property> <property name="bonecp.minConnectionsPerPartition">20</property> <property name="bonecp.statementsCacheSize">50</property> <property name="bonecp.releaseHelperThreads">3</property>
<property name="connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</property>
What this means: * Existing users of XWiki will not have to change anything, it'll still work * New users will use bonecp without knowing * Existing users can migrate to bonecp just by changing one line in their hibernate.cfg.xml file
I'd love to do this for 4.3 but we're already quite advanced in the 4.x cycle. That said it's just a one line change in hibernate.cfg.xml in case of problem to go back to DBCP so we could do this for 4.3 which leaves us 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue we'll always be able to release a 4.5.1 that has this one line change to go back to DBCP.
WDYT?
Here's my +1 for this action plan.
Thanks -Vincent
participants (6)
-
Andreas Jonsson -
Denis Gervalle -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol