25 Sep
2012
25 Sep
'12
3:27 p.m.
On Tue, Sep 25, 2012 at 12:47 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
wrote:
> On Tue, Sep 25, 2012 at 12:36 PM, Andreas Jonsson <aj(a)member.fsf.org>
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 <aj(a)member.fsf.org>
wrote:
> >>
> >>> 2012-09-25 10:48, Denis Gervalle skrev:
> >>>> On Tue, Sep 25, 2012 at 1:29 AM, Andreas Jonsson
<aj(a)member.fsf.org>
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-librar…
> >>>>>> *
http://www.jorambarrez.be/blog/2012/04/30/dbcp_vs_c3p0_bonecp/
> >>>>>> *
> >>>>>
>
http://stackoverflow.com/questions/8057110/java-database-connection-pool-bo…
> >>>>>> 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
> >>>>>> devs(a)xwiki.org
> >>>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>>
> >>>>> _______________________________________________
> >>>>> devs mailing list
> >>>>> devs(a)xwiki.org
> >>>>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> devs mailing list
> >>> devs(a)xwiki.org
> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >> _______________________________________________
> >> devs mailing list
> >> devs(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO