myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: [OT but still JSF]: Clustering, session replication, and database, too
Date Sun, 20 Oct 2013 12:44:21 GMT
wow, good point. I don't ever create new users in app. currently, the app
is only 'for-office-use' only, but some day, i'm hoping the app will serve
the customers of the business (and endusers have already mentioned
some/different requirements where customers can login and do some stuff in
the app, specific for customers, of course).

i have already learned to cache 'static' data in @ApplicationScoped; a lot
of lists that show up in selectOneMenu, etc..., are instantiated-and-cached
on startup of the app (and inside the @ApplicationScoped bean).

based on your response, I can definitely cache the user data and some of
the 'static' data in the database. hmmm, i think I am doing that too, on a
few of the tables, but I will have to check that.

of course, omnifaces came up with a way for selectOneMenu to avoid the need
to use @EJB to verify elements in the list (via selectone converter, or
something like that)... i am not using that (yet). your idea, to cache the
'static' lists in database is definitely a better (performance) option than
the omnifaces feature.

evidently, i need to cache more data from my database in my
@ApplicationScoped bean. i love that (CDI) @ApplicationScoped bean!



On Sun, Oct 20, 2013 at 8:30 AM, Mark Struberg <struberg@yahoo.de> wrote:

> With Caching I meant stuff like all the things which do not change often.
>
> There is a big difference between 'almost static' data and between 'living
> data'.
>
> E.g. the User data can surely be cached for 30 minutes. How often do you
> add or change a new user in your system?
> Same for e.g. an amazon catalogue. This can be perfectly be cached for at
> least an hour without having to hit the database again.
> Of course not all data can be cached, but lots of things which are kind of
> 'configuration like' can. And this can take away a lot of hits from the
> database which is then free to serve other more important stuff.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: "Howard W. Smith, Jr." <smithh032772@gmail.com>
> > To: MyFaces Discussion <users@myfaces.apache.org>
> > Cc:
> > Sent: Sunday, 20 October 2013, 13:19
> > Subject: Re: [OT but still JSF]: Clustering, session replication, and
> database, too
> >
> > On Sun, Oct 20, 2013 at 7:07 AM, Howard W. Smith, Jr. <
> > smithh032772@gmail.com> wrote:
> >
> >>
> >>  hmmm, avoid database replication.
> >>
> >
> > honestly, I think HA-JDBC[1] (clustering the database) is all I really
> > need, because my app is quite fast, and only bottleneck is database
> layer.
> > I have seen David Blevins or Mark Struberg say that they reverted to
> > caching much of the data from database (in memory, on startup, I
> > guess/assume) to improve performance, but i wonder if caching the data is
> > really (really) necessary/recommended...
> >
> >
> > [1] http://ha-jdbc.github.io/
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message