jsf 2.0 datatable reload again and again

[Alexander Burger]

Hi,

I did migration from jsf 1.2 with pages written in jsp
to jsf 2.0 same pages now with facelets (xhtml)

in one page I'm using <h:datatable
the table is reading the content from a list from a managed bean.
To get fresh data, I always read data from database in the getList method.

Now, if I call that page, the page reload data from database six times
(means getList is called six times by facelet-page).
when I leave that page over <h:commandButton, it reads again 12 times the
data from database, before it starts the action-method of commanButton.

with jsf 1.2, I can't remember to have that problem.

Is that a problem of jsf 2.0 ?

Anybody with help?

Thanks a lot for any kind of help.

regards
Alex

 

[Arved Sandstrom]

Hi,

I did migration from jsf 1.2 with pages written in jsp
to jsf 2.0 same pages now with facelets (xhtml)

in one page I'm using <h:datatable
the table is reading the content from a list from a managed bean.
To get fresh data, I always read data from database in the getList
method.

Now, if I call that page, the page reload data from database six times
(means getList is called six times by facelet-page).
when I leave that page over <h:commandButton, it reads again 12 times
the data from database, before it starts the action-method of
commanButton.

with jsf 1.2, I can't remember to have that problem.

Is that a problem of jsf 2.0 ?

Anybody with help?

Thanks a lot for any kind of help.

regards
Alex

It won't be a problem with either JSF 1.2 or 2.0, per se. If you have code
in some method - say to access the DB - that gets called many times, it's
unlikely to be much of a mystery as to why it happens. First off, understand
when getters and setters can get called during the JSF lifecycle - it can be
quite useful to implement a "debugging" phase listener that prints out the
start and finish of each of the JSF phases, so that you can see for one
single HTTP request (either an initial view or a form submit) in what phases
the DB calls are taking place. Review some of the better articles or
documentation concerning the JSF lifecycle as well.

It's significant that in the initial view you see 6 calls, and in the
postback you see 2 x 6. To me that means that something about your own code
is causing 6 calls; it's a JSF lifecycle artifact that you see it doubled in
the postback (and this is something you can fix after you figure out why you
have the 6 calls in the initial view).

AHS

 

[Alexander Burger]

Arved Sandstrom wrote:

It won't be a problem with either JSF 1.2 or 2.0, per se. If you have code
in some method - say to access the DB - that gets called many times, it's
unlikely to be much of a mystery as to why it happens. First off,
understand when getters and setters can get called during the JSF
lifecycle - it can be quite useful to implement a "debugging" phase
listener that prints out the start and finish of each of the JSF phases,
so that you can see for one single HTTP request (either an initial view or
a form submit) in what phases the DB calls are taking place. Review some
of the better articles or documentation concerning the JSF lifecycle as
well.

It's significant that in the initial view you see 6 calls, and in the
postback you see 2 x 6. To me that means that something about your own
code is causing 6 calls; it's a JSF lifecycle artifact that you see it
doubled in the postback (and this is something you can fix after you
figure out why you have the 6 calls in the initial view).

thank you for your answer.

well with 6 to 12 :
on another page I have the same problem and there it is:
3 starting the page, and 14 leaving the page.

well, I found in the web:
http://seamframework.org/Documentation/WhyDoesJSFCallMyGetterHundredsOfTimes

seems, other people have similar problems.
but there isn't written a real solution.
Have I really to do the chaching in jsf 2.0 by my own?

what sense does it make, if jsf 2.0 calls the same getter-method,
which is only ones on the whole xhtml-page, several times during one
rendering of the jsf-page?

thank you
regards
Alex

 

[Arved Sandstrom]

thank you for your answer.

well with 6 to 12 :
on another page I have the same problem and there it is:
3 starting the page, and 14 leaving the page.

well, I found in the web:
http://seamframework.org/Documentation/WhyDoesJSFCallMyGetterHundredsOfTimes

seems, other people have similar problems.
but there isn't written a real solution.
Have I really to do the chaching in jsf 2.0 by my own?

what sense does it make, if jsf 2.0 calls the same getter-method,
which is only ones on the whole xhtml-page, several times during one
rendering of the jsf-page?

thank you
regards
Alex

It's not just JSF 2.0; it's also JSF 1.x. Bearing in mind that the backing
bean instance is ultimately where values are stored, it makes sense that in
the RENDER_RESPONSE phase the getters are called to obtain the values to
display. The reason you'll see a second call to getters is that during
PROCESS_VALIDATIONS it's necessary to obtain values on the bean in order to
support value change listeners. This happens in a postback (form submit)
only. Sometimes you'll see even more calls if you have complex page logic
involving values, like to compute a "rendered" attribute.

So this double call during postback is something to anticipate. Don't put
code in your getters that will execute twice if you don't want it to execute
twice. If the code does need to be there - like fetching data from a DB -
then you put in appropriate guards to make sure it executes once only. This
isn't caching - it's understanding the JSF lifecycle and understanding that
getters can execute twice during certain HTTP requests.

As the Seam article mentioned, if you've got value expressions in an
h:column inside h:dataTable, then you can also get considerably more getter
calls. Depending on what your getters are doing (what exactly are the values
in your table, what kind of persistence do you have, etc) then not only are
you loading up a backing list twice but you may also be calling the DB to
populate other columns for each row in that list.

If you can provide an example of an offending page and the corresponding
backing bean it would be helpful.

AHS

 

[Alexander Burger]

Arved Sandstrom wrote:

It's not just JSF 2.0; it's also JSF 1.x. Bearing in mind that the backing
bean instance is ultimately where values are stored, it makes sense that
in the RENDER_RESPONSE phase the getters are called to obtain the values
to display. The reason you'll see a second call to getters is that during
PROCESS_VALIDATIONS it's necessary to obtain values on the bean in order
to support value change listeners. This happens in a postback (form
submit) only. Sometimes you'll see even more calls if you have complex
page logic involving values, like to compute a "rendered" attribute.

So this double call during postback is something to anticipate. Don't put
code in your getters that will execute twice if you don't want it to
execute twice. If the code does need to be there - like fetching data from
a DB - then you put in appropriate guards to make sure it executes once
only. This isn't caching - it's understanding the JSF lifecycle and
understanding that getters can execute twice during certain HTTP requests.

As the Seam article mentioned, if you've got value expressions in an
h:column inside h:dataTable, then you can also get considerably more
getter calls. Depending on what your getters are doing (what exactly are
the values in your table, what kind of persistence do you have, etc) then
not only are you loading up a backing list twice but you may also be
calling the DB to populate other columns for each row in that list.

If you can provide an example of an offending page and the corresponding
backing bean it would be helpful.

ok, thank you for your answer.

there I still found another page with that problem:
http://seamframework.org/Community/HowtoAvoidMethodOrGetterToBeCalledSeveralTimesByCachingResult

well, the getter-Method will give back an object.
that object will be the same during one rendering of the page.
If not, the rendering would get problems, I think.
So why to create that object again and again during one rendering?
I have only one of that getter-method in my xhtml-page.
If there would be more, ok.

And why to call the getter-method during leaving the page?
I ask, if it make sense to call it one time,
but in my case it does it 14 times.

The code is becoming very, very slow that way.

I only can understand, that there is a huge bug in jsf.

regards
Alex

 

[Lew]

Arved Sandstrom wrote:



ok, thank you for your answer.

there I still found another page with that problem:
http://seamframework.org/Community/HowtoAvoidMethodOrGetterToBeCalledSeveralTimesByCachingResult

well, the getter-Method will give back an object.
that object will be the same during one rendering of the page.
If not, the rendering would get problems, I think.
So why to create that object again and again during one rendering?
I have only one of that getter-method in my xhtml-page.
If there would be more, ok.

And why to call the getter-method during leaving the page?
I ask, if it make sense to call it one time,
but in my case it does it 14 times.

The code is becoming very, very slow that way.

I only can understand, that there is a huge bug in jsf.

That is so totally not the case. It's like you didn't read Arved's answer, or
else you ignored it entirely.

The bug is in YOUR code, for not taking into account the JSF lifecycle and
coding to prevent multiple getter calls from being a problem.

 

[Alexander Burger]

That is so totally not the case. It's like you didn't read Arved's
answer, or else you ignored it entirely.

The bug is in YOUR code, for not taking into account the JSF lifecycle and
coding to prevent multiple getter calls from being a problem.

It's not just JSF 2.0; it's also JSF 1.x. (...)
Sometimes you'll see even more calls if you have complex page logic
involving values, like to compute a "rendered" attribute.
So this double call during postback is something to anticipate.

and please read the links, I posted.
They have similar problems and only work-arounds for that problem.

May be it is MY code.
But I fear, it is not.
And I can't see any sense behind that behaviour of jsf.
It makes code very very slow and what should be the advantage, not to catch
an object?

Well any answer would be welcome. Thank you.

by the way: if I delete the <h:dataTable , the problem disappear in my code.

regards
Alex

 

[Alexander Burger]

Hi,

I still found another page with a solution for that problem:
http://balusc.blogspot.com/2006/06/using-datatables.html

there:

------------------------------------------------------------------------
If you're going to use this bean for other purposes than only showing the
datalist, then you can better move the loading to the getter so that the
data won't be loaded everytime when the bean is constructed. Also use lazy
loading in the getter so that the data won't be loaded everytime when the
getter is called during the bean's life. Here is an example:

public List<MyData> getDataList() {
if (dataList == null) {
loadDataList(); // Preload by lazy loading.
}
return dataList;
}


Session scope: once loaded the dataList will persist during the session and
won't be garbaged after one request in the same session. If you want to
reload the session data every view to get the most recent data, then do as
follows:

public List<MyData> getDataList() {
if (FacesContext.getCurrentInstance().getRenderResponse()) {
loadDataList(); // Reload to get most recent data.
}
return dataList;
}


The FacesContext#getRenderResponse() returns true when this getter is
invoked during the render response phase. This is to prevent duplicate
reloads as this getter can also be invoked during the apply request values
phase or the process validations phase. Also see Debug JSF lifecycle.
------------------------------------------------------------------------


well, I will test that now.
Seems to me also a work-around, but may be best of all I saw until now.


regards
Alex

 

[Arved Sandstrom]

Hi,

I still found another page with a solution for that problem:
http://balusc.blogspot.com/2006/06/using-datatables.html
[ SNIP ]

well, I will test that now.
Seems to me also a work-around, but may be best of all I saw until
now.

regards
Alex

BalusC has good JSF resources, he's worth reading. What he states is along
the same lines of what I had to say. It's worth mentioning that BalusC is
quite hard-line on what he thinks should go into a JSF backing-bean getter,
and he wouldn't be calling this behaviour a bug, and he wouldn't be calling
the coding that you do to address this behaviour a "work-around". I happen
to agree with him. The thing to remember is that in JSF the getters are best
treated as pure getters that will be called multiple times, because that's
what getters are for. Initialization logic is best put elsewhere; if it must
go in a getter and you don't want it to execute multiple times then you code
for that.

No matter what framework you use - JSF or Struts or Spring or Wicket -
you're going to have design peculiarities. In some cases you have to do true
workarounds - this isn't one of them. IMHO.

I might add, I don't know exactly how you are coding your persistence, but
with careful h:dataTable backing list initialization, you should normally be
able to achieve one database call, not 2xN.

AHS

 

[Alexander Burger]

Hi,

I still found another page with a solution for that problem:
http://balusc.blogspot.com/2006/06/using-datatables.
[ SNIP ]

well, I will test that now.
Seems to me also a work-around, but may be best of all I saw until
now.

regards
Alex

BalusC has good JSF resources, he's worth reading. What he states is along
the same lines of what I had to say. It's worth mentioning that BalusC is
quite hard-line on what he thinks should go into a JSF backing-bean
getter, and he wouldn't be calling this behaviour a bug, and he wouldn't
be calling the coding that you do to address this behaviour a
"work-around". I happen to agree with him. The thing to remember is that
in JSF the getters are best treated as pure getters that will be called
multiple times, because that's what getters are for. Initialization logic
is best put elsewhere; if it must go in a getter and you don't want it to
execute multiple times then you code for that.

No matter what framework you use - JSF or Struts or Spring or Wicket -
you're going to have design peculiarities. In some cases you have to do
true workarounds - this isn't one of them. IMHO.

I might add, I don't know exactly how you are coding your persistence, but
with careful h:dataTable backing list initialization, you should normally
be able to achieve one database call, not 2xN.

well, thank you for your answer.

I found a way to avoid multiple database calls and get also fresh data for
every request. It is more complicate as the example of BalusC .

I installed in managed bean a new private like:

private String avoid_multiple_call = new String("");

added getter and setter for that.

now in the getter-method with the database-connection:

if (FacesContext.getCurrentInstance().getRenderResponse()
&& !this.avoid_multiple_call.isequalignorecase(FacesContext.getCurrentInstance().toString())
)
{
-- here is code of database-connection --
this.avoid_multiple_call = FacesContext.getCurrentInstance().toString();
}

ready.

that works.

if I only use the solution of BalusC,
I avoid all the database-calls during the request leaving the page,
but not the multiple database-calls during the first request building the
page.

FacesContext.getCurrentInstance().toString() is unique for one request.
If I set it first time of database-calling, I can avoid to do it second time
and more often.

well, but still the getter-method is called multiple times. Only I avoid
that database-connection is done more than one time. But I can't avoid
loosing still a lot of cpu-time.

for me, it is a huge bug in jsf, a very typically problem of a framework.
I can't see any sense, why jsf should rebuild the same object again and
again during one request. That needs a lot of cpu-time .
I don't think, that any programmer can use that multiple calling of getter
method in a positiv way. If I would change the object, build by the getter
method, from one calling to the next calling, jsf would get problems for
sure. So jsf should build object first time and save it in a cache for one
request. Next time jsf need that object during request, jsf should take
object from cache, and not start to rebuild object again, what would save a
lot of cpu-time.
But well, it works like a framework works: not very clever.

regards
Alex

 

[Lew]

well, thank you for your answer.

I found a way to avoid multiple database calls and get also fresh data for
every request. It is more complicate as the example of BalusC .

I installed in managed bean a new private like:

private String avoid_multiple_call = new String("");

Please follow the Java naming conventions: 'avoidMultipleCall'.

added getter and setter for that.

Why not

private boolean avoidMultipleCall;
?

for me, it is a huge bug in jsf [sic], a very typically problem of a framework.

It's only a "problem" because you label it so.

I can't see any sense, why jsf [sic] should rebuild the same object again and

Then you missed the explanations. Surely you see there is at least a little
sense, based on the repeated explanations. I get that you find it
insufficiently justified.

again during one request. That needs a lot of cpu-time .

Are you cramped for CPU time?

How much more does it need than what you expect?

I don't think, that any programmer can use that multiple calling of getter
method in a positiv way. If I would change the object, build by the getter

In that you are mistaken. Many programmers use JSF in a very positive way,
myself included, not only accepting but relying on that behavior.

But well, it works like a framework works: not very clever.

Actually, it's quite clever indeed, albeit not suited to your requirements.
In fact JSF supplanted frameworks that did not have this feature of multiple
get/set actions, nor a six-layer lifecycle. It was the introduction of those
very details that empowered JSF to be the useful framework that it is.

With great power comes great responsibility. Indeed, the JSF way is
complicated, and definitely requires some study, but only if you wish to
stretch its capabilities to the limit. But understanding even the basics of
how it handles web communications with a true component model, you find that
is clever.

You seem to have formed your negative opinion of JSF without a very thorough
grounding in it, and your responses seem to bypass posts that gave reasons and
perspectives for the issues you raise. Yes, they are real issues, if
approached from a point of view that requires a different paradigm. In that
frameworks are like frameworks, a tautology that need not be pejorative.

JSF abuse I've encountered runs in a rather different direction, the
imposition of ancillary gadgetry atop JSF - Javascript gimcracks and
custom-tag gewgaws with a Spring dynamic dependency-injection base and a
soupçon of AJAX. Phew! Spaghetti has moved but not vanished.

Once you get the hang of JSF, particularly facelets, if you approach it with
simplicity and rather let the framework handle things for you, the ride gets
very smooth.

I'm not a JSF master yet, but I'm to the comfort zone. I'm an XML /
XSD-schema groupie.

Oh, and on the table reload thing, you might consider JPA (Java Persistence
API). The inbuilt level-one cache will buy you amelioration without any
special accommodations for JSF's idiosyncracies on your part. Framework or no
framework, though, you always have to accommodate something, and resource
optimization will always be tricky.

 

[Alexander Burger]

No matter what framework you use - JSF or Struts or Spring or Wicket -
you're going to have design peculiarities. In some cases you have to do
true workarounds - this isn't one of them. IMHO.

for me, it is a huge bug in jsf [sic], a very typically problem of a
framework.

It's only a "problem" because you label it so.

it seems, there exist already a bugreport for that problem:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1253

that bugreport was:
Opened: Fri Aug 14 19:56:00 +0000 2009

if you do more complicate facelets, that problem could cost you minutes(!)
of cpu-time just for one request without workaround.

if there are more problems like that, which are not solved, it could happen,
that good programmers could leave jsf-framework .

regards
Alex

 

[Arved Sandstrom]

No matter what framework you use - JSF or Struts or Spring or
Wicket - you're going to have design peculiarities. In some cases
you have to do true workarounds - this isn't one of them. IMHO.
for me, it is a huge bug in jsf [sic], a very typically problem of a
framework.

It's only a "problem" because you label it so.

it seems, there exist already a bugreport for that problem:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1253

that bugreport was:
Opened: Fri Aug 14 19:56:00 +0000 2009

if you do more complicate facelets, that problem could cost you
minutes(!) of cpu-time just for one request without workaround.

if there are more problems like that, which are not solved, it could
happen, that good programmers could leave jsf-framework .

regards
Alex

It's not a "bug" (defect). It's an issue that someone reported and that is
being tracked for possible future "enhancement" work. I might also note that
it's very specific, and refers to getters being called during computation of
"rendered" attributes, something I referred to in a previous post. Some JSF
developers think that when they've got some spare cycles they might look at
this very narrow situation and improve things.

If I understand your coding situation correctly this has nothing to do with
you.

As for "problems", there are problems and then there are problems. If you'd
really, really love to have serious intricate tear-your-hair-out problems I
invite you to use Oracle ESB or IBM FileNet and try to get complicated
things done. Compared to some of the real dreck out there JSF, even in
1.x versions, hasn't been all that bad. And with all due respect you are in
no position to consider something to be a problem with a piece of software
unless you've been using it for a good while, unless it's undeniably a
defect (e.g. regular NPEs when you try to run an official example). If
you're going to make a career out of being a professional software developer
you need to raise the bar on what you consider to be a problem...and in any
case what professional software developers do when confronted with
challenges is to accept what is, and develop a solution.

AHS

 

[Alexander Burger]

...and in any case what professional software
developers do when confronted with challenges is to accept what is, and
develop a solution.

for me the solution will be to give the managers the advice to avoid jsf, if
possible. But they noticed already, that solution done with jsf is so very
very slow. I saw already very huge jsf-developments, but if you have to
wait minutes for the response ...
The younger developers, just do the programming, don't care what jsf is
doing behind, they accept what is. But I got the job to have a deeper look,
because it is so slow, to slow to sell it to any customer. And I have to
tell them: forget it.

regards
Alex

 

[Arved Sandstrom]

for me the solution will be to give the managers the advice to avoid
jsf, if possible. But they noticed already, that solution done with
jsf is so very very slow. I saw already very huge jsf-developments,
but if you have to wait minutes for the response ...
The younger developers, just do the programming, don't care what jsf
is doing behind, they accept what is. But I got the job to have a
deeper look, because it is so slow, to slow to sell it to any
customer. And I have to tell them: forget it.

regards
Alex

Often technical recommenders have a difficult job - almost by definition the
software or technology that you are evaluating is new to you, and to
everyone else in the organization. I've been in that situation myself. And
rarely is the recommender in a position to take a month (or several) to
really thoroughly understand everything. So nobody reasonable expects a
recommender's recommendations to be perfect.

I can assure you that in this case that your proposed recommendation is way
offbase. I've used Struts 1/2, Wicket, JSF 1.x and 2.0, Seam, Spring MVC,
RoR, ASP.NET MVC, PHP 4/5, C and Perl CGI, you name it, and I have to tell
you, if you think that JSF sucks, then they all do. There isn't a framework
on that list that doesn't have numerous idiosyncracies comparable to the
"problem" you have identified in JSF. And some have more serious real
problems.

I can also assure you that JSF isn't slow. "Minutes for the response"?
That's outlandish. I expect to be able to - inside one single HTTP form
submit request composed of all 6 JSF lifecycle phases - have the form inputs
(and state of the managed beans) configure a ROWNUM-filtered query
constructed by EclipseLink, involving perhaps 2-5 tables, some very large,
get the results back, and have a complex h:dataTable rendered and back to
the client's browser within several seconds, not several minutes. That's
"expect" as in "that's what happens"...assuming competent knowledge of the
technologies I am using. I'm not just making this up - I actually have used
JSF a lot, and I understood and handled the "problem" you are having in the
first few weeks when I read some good articles on the JSF lifecycle.

Personally I don't care if you use JSF. I'm not part of the JSF project, and
although I don't mind the technology I'm not in love with it - to me it's
just a tool. However I feel justified in saying that you're doing a shoddy
service for your managers and for your other developers. I'd love to see the
written recommendation: "I don't understand JSF but I think it's real slow,
so let's not use it".

AHS