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-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
