Re: [xwiki-devs] [VOTE] Change our default Connection Pooling framework for Hibernate to BoneCP

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 > -Vincent > > On Sep 25, 2012, at 12:06 PM, Andreas Jonsson <aj(a)member.fsf.org>

>> 2012-09-25 10:48, Denis Gervalle skrev: >>> On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson <aj(a)member.fsf.org>

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

>>>> fail afterwards. In any case if I configure Hibernate to not use

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

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

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

>>> the pool provider is not aware. This is why we need to set the

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

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

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

>>>> about DBCP. >>>>> I've googled for what connection pooling library to use and I've

>>>> that most people are recommending BoneCP (http://jolbox.com/). >>>>> See: >>>>> *

>>>>> * http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/ >>>>> *

>>>>> The other thing is that we currently have some 300 line of code

>>>> shouldn't have at all and that we need in XWiki just for handling

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

>>>>> What this means: >>>>> * Existing users of XWiki will not have to change anything, it'll

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

>>>> cycle. That said it's just a one line change in hibernate.cfg.xml in

>>>> of problem to go back to DBCP so we could do this for 4.3 which

>>>> 4.3, 4.4 and 4.5 to test this out. And if later on we find an issue

>>>> always be able to release a 4.5.1 that has this one line change to

>>>> to DBCP. >>>>> WDYT? >>>>> >>>>> Here's my +1 for this action plan. >>> Unless BoneCP really provide proven improvements, and not only a

>>> performance increase, that will probably not be tremendous, I am not

>>> in favor of changing a well-know Apache project for a project that as

>>> really a great team of supporter. From the project info page, I see

>>> one name. From the forum, there seems to be serious rumors that the

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs