, or in application scope it the data is shared
beetwen all the users.
Regards
Jose R. Díaz
> -Mensaje original-
> De: Hookom, Jacob [mailto:[EMAIL PROTECTED]
> Enviado el: jueves, 27 de mayo de 2004 21:08
> Para: 'Struts Users Mailing List'
> Asunto: RE: Session
d refetching it all the time, causing high processor usage and low
memory consumption.
-Original Message-
From: Riyad Kalla [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 12:11 PM
To: Struts Users Mailing List
Subject: Re: Session size
On Thursday 27 May 2004 09:53 am, Zhang, L
On Thursday 27 May 2004 09:53 am, Zhang, Larry (L.) wrote:
> It sounds like very promising to me. The only consideration is that caching
> those objects may cause another issue of usage of the memory. And also when
Yes absolutely a concern, which is where you can tune how big your cache for
DAO i
this approach sometimes called object pool?
Thanks.
-Original Message-
From: Riyad Kalla [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 12:25 PM
To: Struts Users Mailing List
Subject: Re: Session size
Hmm, I should clarify what I meant:
The DAO will be at the application scope, so
: Struts Users Mailing List
Subject: Re: Session size
Larry,
It depends on how you load the elements. If you are creating the smaller
objects by first loading the full objects, then just save the time and use
the full ones.
If however you are loading the DisplayObjects directly via a Hibernate
: Thursday, May 27, 2004 11:53 AM
> To: Struts Users Mailing List
> Subject: Re: Session size
>
>
> Mike,
> Good suggestions. I was dealing with something like this recently and
> decided that for me, adding caching at the DAO level:
>
> e.g. List userList = UserDAO.getAllU
Larry,
It depends on how you load the elements. If you are creating the smaller
objects by first loading the full objects, then just save the time and use
the full ones.
If however you are loading the DisplayObjects directly via a Hibernate query
of course that will be magnitudes smaller.
Also
: Session size
Mike,
Good suggestions. I was dealing with something like this recently and decided
that for me, adding caching at the DAO level:
e.g. List userList = UserDAO.getAllUsers();
would offer the biggest performance benefit since it would be:
(a) application wide, instead of per
Why do you like ibatis? I've never heard of it, is it like OScache?
On Thursday 27 May 2004 09:08 am, Paul Barry wrote:
> Sounds like a good idea. I suggest that you look into using something
> like ibatis to handle the caching for you, and it definately won't take
> you a week to implement, even
Sounds like a good idea. I suggest that you look into using something
like ibatis to handle the caching for you, and it definately won't take
you a week to implement, even with the learning curve of ibatis.
Riyad Kalla wrote:
Mike,
Good suggestions. I was dealing with something like this recent
second part of question) at
all?
Thanks.
Larry
-Original Message-
From: Mike Zatko [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 27, 2004 11:50 AM
To: Struts Users Mailing List
Subject: Re: Session size
I personally think its too big. Large amounts of data like that should
be put in
Mike,
Good suggestions. I was dealing with something like this recently and decided
that for me, adding caching at the DAO level:
e.g. List userList = UserDAO.getAllUsers();
would offer the biggest performance benefit since it would be:
(a) application wide, instead of per session
(b) returned
I personally think its too big. Large amounts of data like that should
be put in request scope so that it gets flushed out of memory right
away. If you need the data to be persistent through the user's session
lifetime, mabye try serializing it to a database. Of course, different
situations cal
Larry,
Good question. I am curious what others think about this situation as well.
On Thursday 27 May 2004 08:24 am, Zhang, Larry (L.) wrote:
> It is apparent true that if the session size is big, the performance will
> be negatively affected. The question is that how to actively control the
> siz
14 matches
Mail list logo
