FTR Hibernate 4 supports multi-tenance: http://docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html/ch16.html
-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
