cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo Rivera <>
Subject Re: About Auth Framework -> Caching
Date Sat, 21 Sep 2002 10:51:35 GMT
Many thanks Alan. Of course it helped.

Antonio Gallardo

El Sábado, 21 de Septiembre de 2002 04:58, Alan Hodgkinson escribió:
> Antonio Gallardo Rivera wrote:
> > I have a little web application with aprox. 123 pages. I need to setup
> > the users and groups permisions to this pages. I am using the
> > Authentication Framework. All this permisions are stored in a database in
> > the server. The question is:
> >
> > Where are all the session data stored or mantained?
> On the server in the JSP container.
> > I ask this because I need to know what is the cost of read once and store
> > all this data inside the user session vrs. Retrieve a value from the
> > database on every access (using the user ID).
> >
> > I know this is a trade off between database transacctions vrs. network
> > bandwidth.
> No, it not a transaction vs. network bandwidth, since the session
> data is available locally on the server to your Cocoon Java classes.
> In fact, if your database server is on a separate machine you'll
> need some more bandwidth to talk to it. :)
> Caching user specific information in the session is a normal trick for
> boosting performance. You just need to be aware that database updates
> from other users or administrators may make it out of date. Typically
> you need to restart the application or implement some sort of 'reset'
> mechanism that gets triggered when a database update occurs that
> affects the cached data.
> Another trick is to have a global cache accessable to all users. You
> then provide accessor methods that could go to the database in the
> data hasn't been read yet. If I was doing this now I would use Avalon
> components as the basis of a caching system.
> Yet another trick is to cache your data globally and provide a link
> from the session. When the session expires you can retain (some of)
> the cached data. A typical use is to keep the entire user profile
> information in-memory. This makes logins fast, and is also nice if
> the same users log in and out a lot.
> I worked on JSP based systems where we cached _lots_ of global data.
> In our case it was reference data from a database, which almost never
> got changed. We just restarted the application after a reference
> data update. The caches allowed us to simplify our SQL joins
> considerably, making the DB requests much faster.
> We loaded the caches at system start. This made the delivery of the
> very first page extremely slow (requesting one page was part of the
> start up procedure), but after that it was fast.
> A nice hack to stop your global data from being garbage collected is
> to register (e.g. put() ) your global context (which would contain
> references to all your caches) into the system properties. Yeah, it's
> ugly.. but it works. [If anyone knows a cleaner trick, let me know.]
> A note about performance issues: Often we make the wrong assumptions.
> If you write maintainable code, which is what the Avalon framework
> encourages, it's often better to carefully define the interfaces, and
> just throw up some basic code get the system running. Then find the
> bottlenecks (which are often in surprising places) and refactor as
> necessary.
> Hope this helped.
> Best wishes,
> Alan.
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <>
> To unsubscribe, e-mail:     <>
> For additional commands, e-mail:   <>

Please check that your question  has not already been answered in the
FAQ before posting.     <>

To unsubscribe, e-mail:     <>
For additional commands, e-mail:   <>

View raw message