2012-09-25 15:27, Denis Gervalle skrev:
> 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.
So, are you saying that the implementation idea I mentioned will not work?
Here is again what I wrote:
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.
Best Regards,
/Andreas
>
> 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
>>
>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
