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. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
