See below. On Sep 25, 2012, at 10:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote: 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=%2Fcommo… 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-j… 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….

2012-09-25 10:48, Denis Gervalle skrev: 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

2012-09-25 12:12, Vincent Massol skrev: 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

On Tue, Sep 25, 2012 at 12:47 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com > On Tue, Sep 25, 2012 at 12:36 PM, Andreas Jonsson &lt;aj(a)member.fsf.org&gt; > > 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 &lt;aj(a)member.fsf.org&gt; > >> > >>> 2012-09-25 10:48, Denis Gervalle skrev: > >>>> On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson &lt;aj(a)member.fsf.org&gt; > >>>> > >>>>> 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-librar… > >>>>>> * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ > >>>>>> * > >>>>> > http://stackoverflow.com/questions/8057110/java-database-connection-pool-bo… > >>>>>> 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 > >>>>>> devs(a)xwiki.org > >>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >>>>>> > >>>>> _______________________________________________ > >>>>> devs mailing list > >>>>> devs(a)xwiki.org > >>>>> http://lists.xwiki.org/mailman/listinfo/devs > >>>>> > >>>> > >>> _______________________________________________ > >>> devs mailing list > >>> devs(a)xwiki.org > >>> http://lists.xwiki.org/mailman/listinfo/devs > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

On Tue, Sep 25, 2012 at 3:27 PM, Denis Gervalle &lt;dgl(a)softec.lu&gt; wrote: 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. -- Thomas Mortagne