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-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 >> >>>>> >> >>>> >> >>> _______________________________________________ >> >>> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
