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]>
