Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 1518 invoked by uid 500); 21 Sep 2002 10:48:11 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 1407 invoked from network); 21 Sep 2002 10:48:10 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Antonio Gallardo Rivera Organization: AG Software, S. A. To: cocoon-users@xml.apache.org Subject: Re: About Auth Framework -> Caching Date: Sat, 21 Sep 2002 04:51:35 -0600 User-Agent: KMail/1.4.3 References: <200209201630.41305.agallardo@agsoftware.dnsalias.com> <3D8C50C7.D21253B9@softxs.ch> In-Reply-To: <3D8C50C7.D21253B9@softxs.ch> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209210451.35845.agallardo@agsoftware.dnsalias.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Many thanks Alan. Of course it helped. Antonio Gallardo El S=E1bado, 21 de Septiembre de 2002 04:58, Alan Hodgkinson escribi=F3: > Antonio Gallardo Rivera wrote: > > I have a little web application with aprox. 123 pages. I need to setu= p > > the users and groups permisions to this pages. I am using the > > Authentication Framework. All this permisions are stored in a databas= e 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 s= tore > > 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. networ= k > > 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: