25 Sep
2012
25 Sep
'12
12:02 p.m.
On Tue, Sep 25, 2012 at 11:24 AM, Vincent Massol <vincent(a)massol.net> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
See below.
On Sep 25, 2012, at 10:48 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
All
potential
Sure, I have never said that DBCP is perfect. We are not discussing about
choosing it, we are currently using it and unless you express other real
concerns than hypothetical performance improvement, I would not change it
for BoneCP. If we were starting from scratch, the comparison of those
library would be different. I found BoneCP really appealing in regards to
technical matters, but I do not see it as a well contributed project, and
its "owner" seems to have other concerns now.
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. 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.
http://stackoverflow.com/questions/5640146/java-jdbc-connection-pool-librar…
http://stackoverflow.com/questions/8057110/java-database-connection-pool-bo…
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:
>> *
> >>
>> 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.
Unless BoneCP really provide proven improvements, and not only a
WDYT?
Here's my +1 for this action plan.
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.
I understand. You should also consider that Apache DBCP is well known for:
* being slow
* being full of bugs
* having a stalled development
At least that's what I keep seeing mentioned in all my google everywhere.
I think you shouldn't think Apache == Good. At least not for Commons.
Commons libs can be very small and maintained by very few people.
If you check http://commons.apache.org/dbcp/team-list.html you'll see
several committers.
But if you check
http://svnsearch.org/svnsearch/repos/ASF/search?view=plot&path=%2Fcommo…
see that only 2 committers have been active since
2009.
Do not make me said what I have not. I think Apache projects get better
reputations in regards to business users than a standalone project. There
is also more chance to see a apache project taken over than a standalone
project. But I am not a so big fan of Apache.
You should also note that Tomcat 7 has implemented its
own connection
pooling thus dropping DBCP even though they're both in apache land… you
should ask why. I don't know the internal story but here's what they say:
http://stackoverflow.com/questions/520585/connection-pooling-options-with-j…
Again, I am not against changing if we have real value for that change.
Currently the value of BoneCP is not worst the risk incurred by its lack of
maintenance. Improve the balance, and I will reconsider my vote.
Thanks
-Vincent
PS: I don't disagree with your analysis but we shouldn't be too fearful
either of making discoveries/changes. Provided we can control them and
revert easily it's not a bad thing to discover new stuff.
PPS: BoneCP could not be the best choice. Maybe C3P0 is better now or
maybe the new Tomcat Connection Pool is better.
PPPS: In any case I'm not going to make any change till I get to the
bottom of this issue with HSQLDB in virtual mode….
PS: I think we are agreeing :)
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