Bug 724693 (BRMS-576) - When ModeShape is used with Oracle 10g, the Guvnor operations that use the JCR backend are very slow (need to retest with Oracle 11g)
Summary: When ModeShape is used with Oracle 10g, the Guvnor operations that use the J...
Keywords:
Status: CLOSED DEFERRED
Alias: BRMS-576
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: Modeshape
Version: 5.1.0 GA
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: BRMS 5.2.0.GA
Assignee: Petr Široký
QA Contact: Petr Široký
URL: http://jira.jboss.org/jira/browse/BRM...
Whiteboard:
Depends On: BRMS-638
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-30 15:17 UTC by Petr Široký
Modified: 2011-09-21 07:17 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Oracle 10g database (remote) ModeShape 2.2.x, patched (see SOA-2976)
Last Closed: 2011-09-21 07:17:36 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker BRMS-576 0 None Closed When ModeShape is used with Oracle 10g, the Guvnor operations that use the JCR backend are very slow. 2012-03-14 00:23:58 UTC
Red Hat Issue Tracker MODE-1133 0 None Resolved When Oracle 10g is used, the operations that are connected with getting/storing data are very slow. 2012-03-14 00:23:58 UTC

Description Petr Široký 2011-03-30 15:17:38 UTC 
securitylevel_name: Public

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.
Comment 1 Petr Široký 2011-03-30 15:22:39 UTC 
Link: Added: This issue Cloned to BRMS-577
Comment 2 Petr Široký 2011-04-04 09:08:31 UTC 
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.
Comment 3 Tihomir Surdilovic 2011-06-02 22:17:29 UTC 
assigning to kurt to take a look at and provide any input
Comment 6 Anne-Louise Tangring 2011-08-01 15:23:23 UTC 
Oracle 10g is no longer supported as of BRMS 5.2.0. This will be retested with Oracle 11g.
Comment 7 Lukáš Petrovický 2011-08-01 15:24:51 UTC 
Petr, would you re-test please?
Comment 8 Lukáš Petrovický 2011-08-12 14:28:34 UTC 
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.
Comment 9 Van Halbert 2011-08-12 15:45:45 UTC 
MODE-1225 has been resolved for the next build, which resolves bug 724798.  This should allow Oracle 11g to be tested.
Comment 10 Len DiMaggio 2011-08-29 16:49:30 UTC 
Changing status to ON_QA - requires QE to retest.
Comment 11 Lukáš Petrovický 2011-09-21 07:17:36 UTC 
Modeshape performance issues will be resolved at a later release.
Note You need to log in before you can comment on or make changes to this bug.