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-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. 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%2Fproper%2Fdbcp&plotsort=commits 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-jdbc-dbcp-vs-c3p0/3481821#3481821 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
