Bug 794456 (JBEPP-1496) - WebAppController needs to start RequestLifeCycle for every processing (including static resource processing)
Summary: WebAppController needs to start RequestLifeCycle for every processing (includ...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: JBEPP-1496
Product: JBoss Enterprise Portal Platform 5
Classification: JBoss
Component: Portal
Version: 5.2.0.GA
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 5.2.1.GA
Assignee: mposolda
QA Contact:
URL: http://jira.jboss.org/jira/browse/JBE...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-31 12:26 UTC by mposolda
Modified: 2012-03-28 00:27 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-01-31 12:32:38 UTC
Type: Enhancement
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBEPP-1496 0 Major Closed WebAppController needs to start RequestLifeCycle for every processing (including static resource processing) 2012-09-28 10:51:17 UTC

Description mposolda 2012-01-31 12:26:52 UTC
project_key: JBEPP

See GTNPORTAL-2340

Comment 1 mposolda 2012-01-31 12:32:38 UTC
Release Notes Docs Status: Added: Not Yet Documented
Release Notes Text: Added: PROBLEM: WebAppController needs to start RequestLifeCycle for every processing (including static resource processing). And starting of requestLifeCycle is quite expensive as it requires starting of Hibernate transaction among other things. This means that we need to start Hibernate transaction for processing of images and other static resources, which does not makes sense and it's not ideal from performance perspective.

SOLUTION: Adding new method to WebRequestHandler class, so handlers can decide if they need to start RequestLifeCycle or not. Handlers for sending requests to portal (like PortalRequestHandler) needs to start transaction, but handlers for processing static resources (like StaticResourceHandler) don't need it. So now we are not starting Hibernate transaction anymore for processing images.


Comment 2 mposolda 2012-01-31 12:44:47 UTC
Link: Added: This issue is related to GTNPORTAL-2340


Comment 3 mposolda 2012-03-22 19:45:05 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
CAUSE: WebAppController needs to start
RequestLifeCycle for every processing (including static resource processing).
And starting of requestLifeCycle is quite expensive as it requires starting of
Hibernate transaction among other things. This means that we need to start
Hibernate transaction for processing of images and other static resources,
which does not makes sense and it's not ideal from performance perspective.

FIX: Adding new method to WebRequestHandler class, so handlers can decide
if they need to start RequestLifeCycle or not. Handlers for sending requests to
portal (like PortalRequestHandler) needs to start transaction, but handlers for
processing static resources (like StaticResourceHandler) don't need it. So now
we are not starting Hibernate transaction anymore for processing images.

Comment 4 Jared MORGAN 2012-03-28 00:27:25 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,12 +1 @@
-CAUSE: WebAppController needs to start
+A performance impact was discovered in the WebAppController that required RequestLifeCycle to be started for all processing, including static resources. Because RequestLifeCycle requires Hibernate transactions, this service needed to be started for all processing, which introduced a performance implication. The fix adds a new method (getRequireLifeCycle) to the WebRequestHandler class, which allows handlers to decide whether RequestLifeCycle is required to complete the transaction. Hibernate is only called for handlers sending requests to the portal, and not for handlers processing images.-RequestLifeCycle for every processing (including static resource processing).
-And starting of requestLifeCycle is quite expensive as it requires starting of
-Hibernate transaction among other things. This means that we need to start
-Hibernate transaction for processing of images and other static resources,
-which does not makes sense and it's not ideal from performance perspective.
-
-FIX: Adding new method to WebRequestHandler class, so handlers can decide
-if they need to start RequestLifeCycle or not. Handlers for sending requests to
-portal (like PortalRequestHandler) needs to start transaction, but handlers for
-processing static resources (like StaticResourceHandler) don't need it. So now
-we are not starting Hibernate transaction anymore for processing images.


Note You need to log in before you can comment on or make changes to this bug.