Why JSF calls getters multiple times

by

This is caused by the nature of deferred expressions #{} (note that “legacy” standard expressions ${} behave exactly the same when Facelets is used instead of JSP). The deferred expression is not immediately evaluated, but created as a ValueExpression object and the getter method behind the expression is executed everytime when the code calls ValueExpression#getValue().

This will normally be invoked one or two times per JSF request-response cycle, depending on whether the component is an input or output component (learn it here). However, this count can get up (much) higher when used in iterating JSF components (such as <h:dataTable> and <ui:repeat>), or here and there in a boolean expression like the rendered attribute. JSF (specifically, EL) won’t cache the evaluated result of the EL expression at all as it may return different values on each call (for example, when it’s dependent on the currently iterated datatable row).

Evaluating an EL expression and invoking a getter method is a very cheap operation, so you should generally not worry about this at all. However, the story changes when you’re performing expensive DB/business logic in the getter method for some reason. This would be re-executed everytime!

Getter methods in JSF backing beans should be designed that way that they solely return the already-prepared property and nothing more, exactly as per the Javabeans specification. They should not do any expensive DB/business logic at all. For that the bean’s @PostConstruct and/or (action)listener methods should be used. They are executed only once at some point of request-based JSF lifecycle and that’s exactly what you want.

Here is a summary of all different right ways to preset/load a property.

public class Bean {

    private SomeObject someProperty;

    @PostConstruct
    public void init() {
        // In @PostConstruct (will be invoked immediately after construction and dependency/property injection).
        someProperty = loadSomeProperty();
    }

    public void onload() {
        // Or in GET action method (e.g. <f:viewAction action>).
        someProperty = loadSomeProperty();
    }           

    public void preRender(ComponentSystemEvent event) {
        // Or in some SystemEvent method (e.g. <f:event type="preRenderView">).
        someProperty = loadSomeProperty();
    }           

    public void change(ValueChangeEvent event) {
        // Or in some FacesEvent method (e.g. <h:inputXxx valueChangeListener>).
        someProperty = loadSomeProperty();
    }

    public void ajaxListener(AjaxBehaviorEvent event) {
        // Or in some BehaviorEvent method (e.g. <f:ajax listener>).
        someProperty = loadSomeProperty();
    }

    public void actionListener(ActionEvent event) {
        // Or in some ActionEvent method (e.g. <h:commandXxx actionListener>).
        someProperty = loadSomeProperty();
    }

    public String submit() {
        // Or in POST action method (e.g. <h:commandXxx action>).
        someProperty = loadSomeProperty();
        return "outcome";
    }

    public SomeObject getSomeProperty() {
        // Just keep getter untouched. It isn't intented to do business logic!
        return someProperty;
    }

}

Note that you should not use bean’s constructor or initialization block for the job because it may be invoked multiple times if you’re using a bean management framework which uses proxies, such as CDI.

If there are for you really no other ways, due to some restrictive design requirements, then you should introduce lazy loading inside the getter method. I.e. if the property is null, then load and assign it to the property, else return it.

    public SomeObject getSomeProperty() {
        // If there are really no other ways, introduce lazy loading.
        if (someProperty == null) {
            someProperty = loadSomeProperty();
        }

        return someProperty;
    }

This way the expensive DB/business logic won’t unnecessarily be executed on every single getter call.

See also:

More Related Contents:

  1. How can I determine whether a 2D Point is within a Polygon?
  2. Why is MATLAB so fast in matrix multiplication?
  3. INC instruction vs ADD 1: Does it matter?
  4. DataFrame / Dataset groupBy behaviour/optimization
  5. Excel VBA Performance – 1 million rows – Delete rows containing a value, in less than 1 min
  6. Is there a penalty when base+offset is in a different page than the base?
  7. What’s the most efficient way to test if two ranges overlap?
  8. What happens after a L2 TLB miss?
  9. What does gcc’s ffast-math actually do?
  10. Are there any modern CPUs where a cached byte store is actually slower than a word store?
  11. Why is reshape so fast? (Spoiler: Copy-on-Write)
  12. JMeter : How to record HTTPS traffic?
  13. What is the most ridiculous pessimization you’ve seen? [closed]
  14. What are the major performance hitters in AS3 aside from rendering vectors?
  15. Find number in sorted matrix (Rows n Columns) in O(log n) [duplicate]
  16. Which loop is faster, while or for?
  17. bsxfun implementation in matrix multiplication
  18. Why is the final reduce step extremely slow in this MapReduce? (HiveQL, HDFS MapReduce)
  19. Unexpectedly poor and weirdly bimodal performance for store loop on Intel Skylake
  20. Why can’t my ultraportable laptop CPU maintain peak performance in HPC
  21. How should I calculate Ramp-up time in Jmeter
  22. Why is the getter called so many times by the rendered attribute?
  23. javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL does not work anymore since Java EE 7 / EL 3.0
  24. Performance optimisations of x86-64 assembly – Alignment and branch prediction
  25. How are cache memories shared in multicore Intel CPUs?
  26. why is data structure alignment important for performance?
  27. Return address prediction stack buffer vs stack-stored return address?
  28. When should we use prefetch?
  29. Relative performance of x86 inc vs. add instruction
  30. Efficient sse shuffle mask generation for left-packing byte elements

Leave a Comment