Red Hat Bugzilla – Bug 724693
When ModeShape is used with Oracle 10g, the Guvnor operations that use the JCR backend are very slow (need to retest with Oracle 11g)
Last modified: 2011-09-21 03:17:36 EDT
Guvnor operations that are connected with getting/storing data to JCR backend are taking too much time (up to 20 times more comparing to JR) when ModeShape with Oracle 10g as store is used.
With MySQL 5.1 and PostgreSQL 8.4, this is not the issue. It's happening (so far) only with Oracle db.
For the test details see BRMS-502.
Link: Added: This issue Cloned to BRMS-577
Just to clarify the difference between this issue and BRMS-502. BRMS-502 is general performance degradation issue, that is happening with all databases. This issue, on the other hand, is related only to Oracle database. Following numbers were measured with local MySQL 5.1 and local Oracle 10g (test is same as in BRMS-502):
ModeShape + MySQL 5.1: loop1= 32s, loop50= 45s, loop100= 56s, loop150= 70s
ModeShape + Oracle 10g: loop1= 61s, loop50= 121s, loop100= 170s
Jackrabbit + MySQL 5.1: loop1= 9s, loop50= 9s, loop100= 9s, loop150= 9s
Jackrabbit + Oracle 10g: loop1= 11s, loop50= 11s, loop100= 10.5s, loop150= 10.5s
With Jackrabbit there is not major difference between Oracle and MySQL, but with ModeShape the loop time is much bigger (and increases faster) when Oracle is used.
assigning to kurt to take a look at and provide any input
Oracle 10g is no longer supported as of BRMS 5.2.0. This will be retested with Oracle 11g.
Petr, would you re-test please?
This cannot be re-tested unless Modeshape is able to deploy on Oracle 11g. Adding bug 724798 to the dependencies, it needs to be fixed first.
MODE-1225 has been resolved for the next build, which resolves bug 724798. This should allow Oracle 11g to be tested.
Changing status to ON_QA - requires QE to retest.
Modeshape performance issues will be resolved at a later release.