25 Sep
2012
25 Sep
'12
12:06 p.m.
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:
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
2012-09-24 17:26, Vincent Massol skrev:
You should, we really do scary stuff to support multiple DB, and also
dynamic mapping.
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. 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. 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
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.
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://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. 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