You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com> on 2002/09/21 00:30:41 UTC
About Auth Framework
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?
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.
Many thanks in advance,
Antonio Gallardo.
P.S: I am using XSP, Cocoon 2.1
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About Auth Framework -> Caching
Posted by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com>.
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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About Auth Framework -> Caching
Posted by Alan Hodgkinson <al...@softxs.ch>.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: About Auth Framework
Posted by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com>.
To answer my question: :)
From Cocoon docs:
A session is a data storage which resides on the server and records
information about one single user. Cocoon creates a session on demand and
from that point of time the user is tracked and information can be stored
inside the session. Each following request of this user is linked to the one
specific session, so there is always only one session per user on the server.
To avoid a fast growing amount of sessions on the server and the overcome
potential security problems, a session has usually a valid period of time. If
during this period no new request comes in from the user, the session object
on the server will be destroyed by the server (this period of time is called
session timeout). The web application often allows a user to explictly
destroy a session.
The usual web applications create sessions during login of a user and destroy
them when the user logs out.
Antonio Gallardo
El Viernes, 20 de Septiembre de 2002 16:30, Antonio Gallardo Rivera escribió:
> 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?
>
> 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.
>
> Many thanks in advance,
>
> Antonio Gallardo.
>
> P.S: I am using XSP, Cocoon 2.1
>
> ---------------------------------------------------------------------
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>