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-choice-in-2011-2012 > > * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ > > * > http://stackoverflow.com/questions/8057110/java-database-connection-pool-bonecp-vs-dbpool-vs-c3p0 > > > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
