You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jim O'Callaghan <ji...@peritussolutions.com> on 2010/01/10 16:58:05 UTC
Advice on Tapestry5 best practise for user session data
I'm trying to work out the best approach to passing a pojo around a system
that is to be used for caching some user relevant data (keys only, and
otherwise minimal amounts of information) on a per-user basis. The data is
to be used in a large number of db queries in the system (various persisted
config demarcated by company / division codes) during a user's session, and
as such I don't want to be reloading it from the db on a per-user basis each
time. I would like to use a pojo, and do an initial load of the data when
the user logs in (or lazy-load and cache on getter access of specific data),
and then have it available around various parts of the system (esp. the
service and possibly DAO layer). Can some of you more experienced Tapestry5
users advise on how best to approach this scenario? Is an injected service
containing a map of pojos keyed on user a bad idea? Thanks for any
suggestions.
Regards,
Jim.
RE: Advice on Tapestry5 best practise for user session data
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Ville, Thiago,
Thanks for the replies. They well very helpful. ApplicationStateManager works perfectly for my needs.
Regards,
Jim.
-----Original Message-----
From: Ville Virtanen [mailto:ville.virtanen@cerion.fi]
Sent: 10 January 2010 18:11
To: users@tapestry.apache.org
Subject: RE: Advice on Tapestry5 best practise for user session data
Hi,
as Thiago said you can access the application state using
ApplicationStateManager in services, but beware that this approach doesn't
work if there is no request.
So, you cannot use the service anymore if the calling code is, let's say
some sort of batch job that has actually nothing to do with a web request.
IMHO web related stuff should never be accessed in low level services / dal
to avoid this. If you can live with that restriction it is ok to use
ApplicationStateManager.
- Ville
jc1001 wrote:
>
> Eric, Juan,
>
> Thanks for the replies. I can see how this would work between
> pages/components but how would it work say from a service that was used as
> some sort of entity manager? Would it be a question of passing it as a
> parameter to each method call on the service that requires data from it or
> is there a way to access it from a service? As you can probably guess,
> I'm
> trying to minimise interface / method signature changes? Thanks.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Juan E. Maya [mailto:maya.juan@gmail.com]
> Sent: 10 January 2010 16:47
> To: Tapestry users
> Subject: Re: Advice on Tapestry5 best practise for user session data
>
>
> I would also use a @SessionState pojo. The approach of the service
> having a map wouldn't work in a clustered environment.
>
> On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson
> <er...@gmail.com> wrote:
>> POJOs can be stored as @SessionState variables *if* they're
>> serializable (as I understand it), would that work?
>>
>> I can't weigh in on the pros and cons of memory usage etc over
>> your injected service idea, but using @SessionState would
>> be simpler code-wise until you had reason to change....
>>
>> FWIW
>> Erick
>>
>> On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan
>> <ji...@peritussolutions.com>wrote:
>>
>>> I'm trying to work out the best approach to passing a pojo around a
> system
>>> that is to be used for caching some user relevant data (keys only, and
>>> otherwise minimal amounts of information) on a per-user basis. The data
> is
>>> to be used in a large number of db queries in the system (various
> persisted
>>> config demarcated by company / division codes) during a user's session,
> and
>>> as such I don't want to be reloading it from the db on a per-user basis
>>> each
>>> time. I would like to use a pojo, and do an initial load of the data
> when
>>> the user logs in (or lazy-load and cache on getter access of specific
>>> data),
>>> and then have it available around various parts of the system (esp. the
>>> service and possibly DAO layer). Can some of you more experienced
>>> Tapestry5
>>> users advise on how best to approach this scenario? Is an injected
> service
>>> containing a map of pojos keyed on user a bad idea? Thanks for any
>>> suggestions.
>>>
>>> Regards,
>>> Jim.
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Advice-on-Tapestry5-best-practise-for-user-session-data-tp27099574p27100792.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Advice on Tapestry5 best practise for user session data
Posted by Ville Virtanen <vi...@cerion.fi>.
Hi,
as Thiago said you can access the application state using
ApplicationStateManager in services, but beware that this approach doesn't
work if there is no request.
So, you cannot use the service anymore if the calling code is, let's say
some sort of batch job that has actually nothing to do with a web request.
IMHO web related stuff should never be accessed in low level services / dal
to avoid this. If you can live with that restriction it is ok to use
ApplicationStateManager.
- Ville
jc1001 wrote:
>
> Eric, Juan,
>
> Thanks for the replies. I can see how this would work between
> pages/components but how would it work say from a service that was used as
> some sort of entity manager? Would it be a question of passing it as a
> parameter to each method call on the service that requires data from it or
> is there a way to access it from a service? As you can probably guess,
> I'm
> trying to minimise interface / method signature changes? Thanks.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Juan E. Maya [mailto:maya.juan@gmail.com]
> Sent: 10 January 2010 16:47
> To: Tapestry users
> Subject: Re: Advice on Tapestry5 best practise for user session data
>
>
> I would also use a @SessionState pojo. The approach of the service
> having a map wouldn't work in a clustered environment.
>
> On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson
> <er...@gmail.com> wrote:
>> POJOs can be stored as @SessionState variables *if* they're
>> serializable (as I understand it), would that work?
>>
>> I can't weigh in on the pros and cons of memory usage etc over
>> your injected service idea, but using @SessionState would
>> be simpler code-wise until you had reason to change....
>>
>> FWIW
>> Erick
>>
>> On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan
>> <ji...@peritussolutions.com>wrote:
>>
>>> I'm trying to work out the best approach to passing a pojo around a
> system
>>> that is to be used for caching some user relevant data (keys only, and
>>> otherwise minimal amounts of information) on a per-user basis. The data
> is
>>> to be used in a large number of db queries in the system (various
> persisted
>>> config demarcated by company / division codes) during a user's session,
> and
>>> as such I don't want to be reloading it from the db on a per-user basis
>>> each
>>> time. I would like to use a pojo, and do an initial load of the data
> when
>>> the user logs in (or lazy-load and cache on getter access of specific
>>> data),
>>> and then have it available around various parts of the system (esp. the
>>> service and possibly DAO layer). Can some of you more experienced
>>> Tapestry5
>>> users advise on how best to approach this scenario? Is an injected
> service
>>> containing a map of pojos keyed on user a bad idea? Thanks for any
>>> suggestions.
>>>
>>> Regards,
>>> Jim.
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Advice-on-Tapestry5-best-practise-for-user-session-data-tp27099574p27100792.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Advice on Tapestry5 best practise for user session data
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sun, 10 Jan 2010 15:09:30 -0200, Jim O'Callaghan
<jc...@yahoo.co.uk> escreveu:
> Thanks for the replies. I can see how this would work between
> pages/components but how would it work say from a service that was used
> as some sort of entity manager? Would it be a question of passing it as
> a
> parameter to each method call on the service that requires data from it
> or is there a way to access it from a service?
Use the ApplicationStateManager service to manipulate session state
objects in other services.
By the way, you can use some sort of cache to avoid hitting the database
all the time. You can do it easily if you're using Hibernate (second-level
cache).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Sócio, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Advice on Tapestry5 best practise for user session data
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Eric, Juan,
Thanks for the replies. I can see how this would work between
pages/components but how would it work say from a service that was used as
some sort of entity manager? Would it be a question of passing it as a
parameter to each method call on the service that requires data from it or
is there a way to access it from a service? As you can probably guess, I'm
trying to minimise interface / method signature changes? Thanks.
Regards,
Jim.
-----Original Message-----
From: Juan E. Maya [mailto:maya.juan@gmail.com]
Sent: 10 January 2010 16:47
To: Tapestry users
Subject: Re: Advice on Tapestry5 best practise for user session data
I would also use a @SessionState pojo. The approach of the service
having a map wouldn't work in a clustered environment.
On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson
<er...@gmail.com> wrote:
> POJOs can be stored as @SessionState variables *if* they're
> serializable (as I understand it), would that work?
>
> I can't weigh in on the pros and cons of memory usage etc over
> your injected service idea, but using @SessionState would
> be simpler code-wise until you had reason to change....
>
> FWIW
> Erick
>
> On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan
> <ji...@peritussolutions.com>wrote:
>
>> I'm trying to work out the best approach to passing a pojo around a
system
>> that is to be used for caching some user relevant data (keys only, and
>> otherwise minimal amounts of information) on a per-user basis. The data
is
>> to be used in a large number of db queries in the system (various
persisted
>> config demarcated by company / division codes) during a user's session,
and
>> as such I don't want to be reloading it from the db on a per-user basis
>> each
>> time. I would like to use a pojo, and do an initial load of the data
when
>> the user logs in (or lazy-load and cache on getter access of specific
>> data),
>> and then have it available around various parts of the system (esp. the
>> service and possibly DAO layer). Can some of you more experienced
>> Tapestry5
>> users advise on how best to approach this scenario? Is an injected
service
>> containing a map of pojos keyed on user a bad idea? Thanks for any
>> suggestions.
>>
>> Regards,
>> Jim.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Advice on Tapestry5 best practise for user session data
Posted by "Juan E. Maya" <ma...@gmail.com>.
I would also use a @SessionState pojo. The approach of the service
having a map wouldn't work in a clustered environment.
On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson
<er...@gmail.com> wrote:
> POJOs can be stored as @SessionState variables *if* they're
> serializable (as I understand it), would that work?
>
> I can't weigh in on the pros and cons of memory usage etc over
> your injected service idea, but using @SessionState would
> be simpler code-wise until you had reason to change....
>
> FWIW
> Erick
>
> On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan
> <ji...@peritussolutions.com>wrote:
>
>> I'm trying to work out the best approach to passing a pojo around a system
>> that is to be used for caching some user relevant data (keys only, and
>> otherwise minimal amounts of information) on a per-user basis. The data is
>> to be used in a large number of db queries in the system (various persisted
>> config demarcated by company / division codes) during a user's session, and
>> as such I don't want to be reloading it from the db on a per-user basis
>> each
>> time. I would like to use a pojo, and do an initial load of the data when
>> the user logs in (or lazy-load and cache on getter access of specific
>> data),
>> and then have it available around various parts of the system (esp. the
>> service and possibly DAO layer). Can some of you more experienced
>> Tapestry5
>> users advise on how best to approach this scenario? Is an injected service
>> containing a map of pojos keyed on user a bad idea? Thanks for any
>> suggestions.
>>
>> Regards,
>> Jim.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Advice on Tapestry5 best practise for user session data
Posted by Erick Erickson <er...@gmail.com>.
POJOs can be stored as @SessionState variables *if* they're
serializable (as I understand it), would that work?
I can't weigh in on the pros and cons of memory usage etc over
your injected service idea, but using @SessionState would
be simpler code-wise until you had reason to change....
FWIW
Erick
On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan
<ji...@peritussolutions.com>wrote:
> I'm trying to work out the best approach to passing a pojo around a system
> that is to be used for caching some user relevant data (keys only, and
> otherwise minimal amounts of information) on a per-user basis. The data is
> to be used in a large number of db queries in the system (various persisted
> config demarcated by company / division codes) during a user's session, and
> as such I don't want to be reloading it from the db on a per-user basis
> each
> time. I would like to use a pojo, and do an initial load of the data when
> the user logs in (or lazy-load and cache on getter access of specific
> data),
> and then have it available around various parts of the system (esp. the
> service and possibly DAO layer). Can some of you more experienced
> Tapestry5
> users advise on how best to approach this scenario? Is an injected service
> containing a map of pojos keyed on user a bad idea? Thanks for any
> suggestions.
>
> Regards,
> Jim.
>
Re: Advice on Tapestry5 best practise for user session data
Posted by Ville Virtanen <vi...@cerion.fi>.
I would follow this guide:
http://tapestry.apache.org/tapestry5/guide/appstate.html
and make my own app state object, UserSession, which would contain the
needed per user data. (The keys anyway.) There can be services that provide
data based on these keys, and those services should also take care of
caching or more preferably use cache service(s) to do the caching. Cache
service can be implemented using ehcache (http://ehcache.org/) for an
example.
Make interface that the user session implements, then use this interface in
your service and dal methods as a parameter.
This way your system is also cluster ready, as long as the caching mechanism
is cluster friendly too, you could make it using mem-cached
(http://memcached.org/) and one of it's java clients or one of the java
caches.
If you require absolute scaling then throw out the session all together and
live with cookies or encoded urls, this way you can achieve truly stateless
server side and you can add more servers without any sort of sticky sessions
or session replication problems etc.
- Ville
Ps. for 99% of cases using as light user session as possible + pure java
cache is the right way to go afaik, so consider sessionless + memcahced only
if you plan on running the software with loads or servers.
Jim O'Callaghan wrote:
>
> I'm trying to work out the best approach to passing a pojo around a system
> that is to be used for caching some user relevant data (keys only, and
> otherwise minimal amounts of information) on a per-user basis. The data
> is
> to be used in a large number of db queries in the system (various
> persisted
> config demarcated by company / division codes) during a user's session,
> and
> as such I don't want to be reloading it from the db on a per-user basis
> each
> time. I would like to use a pojo, and do an initial load of the data when
> the user logs in (or lazy-load and cache on getter access of specific
> data),
> and then have it available around various parts of the system (esp. the
> service and possibly DAO layer). Can some of you more experienced
> Tapestry5
> users advise on how best to approach this scenario? Is an injected
> service
> containing a map of pojos keyed on user a bad idea? Thanks for any
> suggestions.
>
> Regards,
> Jim.
>
>
--
View this message in context: http://old.nabble.com/Advice-on-Tapestry5-best-practise-for-user-session-data-tp27099574p27100214.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org