You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Cheng Wei Lee <zh...@gmail.com> on 2008/02/22 20:29:55 UTC
Best practices for handling code/lookup tables in Struts 2
Hi all,
In most web applications, it is unavoidable to have some codes/lookup
tables, for example, in a form we may need to display the country list. If
we were to hit the database per request to get this list for displaying in
the dropdown, it would be too expensive. If we load these values during the
filter init(), it cannot be refreshed. What would be the best approach to
handle such scenario?
Thanks!
Chengwei
Re: Best practices for handling code/lookup tables in Struts 2
Posted by Laurie Harper <la...@holoweb.net>.
Cheng Wei Lee wrote:
> Hi all,
>
> In most web applications, it is unavoidable to have some codes/lookup
> tables, for example, in a form we may need to display the country list. If
> we were to hit the database per request to get this list for displaying in
> the dropdown, it would be too expensive. If we load these values during the
> filter init(), it cannot be refreshed. What would be the best approach to
> handle such scenario?
Perhaps caching?
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practices for handling code/lookup tables in Struts 2
Posted by Cheng Wei Lee <zh...@gmail.com>.
Looking into using Hibernate's 2nd level cache. Any tips or pitfalls?
Thanks!
On Sun, Feb 24, 2008 at 2:20 PM, Jeromy Evans <
jeromy.evans@blueskyminds.com.au> wrote:
>
> Cheng Wei Lee wrote:
> > What do you'll think of writing a stateful session bean to hold these
> data
> > and make it gets the data from database once/twice a day?
> >
> >
> I wouldn't use a stateful session bean. It's not really the intent of
> them. When used, it's best that they only last a conversation. You'd
> also need a lot of them (eg. one per type of lookup data), otherwise
> you'll end up with a Repository which is also not a good use of a
> stateful session bean. You wouldn't gain much using a stateful session
> bean but would have to wear a lot of overhead.
>
> The concept is sound though - a provider of these objects that is
> stateful and polls the database periodically (or is triggered by a
> change), but not within a stateful session bean.
> If I had a choice though, I would prefer to rely on a cache provided by
> the ORM/database/other datasource as you can be sure they're thought
> about the issues of optimal cache hits/misses and synchronization.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Best practices for handling code/lookup tables in Struts 2
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Cheng Wei Lee wrote:
> What do you'll think of writing a stateful session bean to hold these data
> and make it gets the data from database once/twice a day?
>
>
I wouldn't use a stateful session bean. It's not really the intent of
them. When used, it's best that they only last a conversation. You'd
also need a lot of them (eg. one per type of lookup data), otherwise
you'll end up with a Repository which is also not a good use of a
stateful session bean. You wouldn't gain much using a stateful session
bean but would have to wear a lot of overhead.
The concept is sound though - a provider of these objects that is
stateful and polls the database periodically (or is triggered by a
change), but not within a stateful session bean.
If I had a choice though, I would prefer to rely on a cache provided by
the ORM/database/other datasource as you can be sure they're thought
about the issues of optimal cache hits/misses and synchronization.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practices for handling code/lookup tables in Struts 2
Posted by Cheng Wei Lee <zh...@gmail.com>.
What do you'll think of writing a stateful session bean to hold these data
and make it gets the data from database once/twice a day?
On Sun, Feb 24, 2008 at 9:20 AM, Jeromy Evans <
jeromy.evans@blueskyminds.com.au> wrote:
> Cheng Wei Lee wrote:
> > Hi all,
> >
> > In most web applications, it is unavoidable to have some codes/lookup
> > tables, for example, in a form we may need to display the country list.
> If
> > we were to hit the database per request to get this list for displaying
> in
> > the dropdown, it would be too expensive. If we load these values during
> the
> > filter init(), it cannot be refreshed. What would be the best approach
> to
> > handle such scenario?
> >
> > Thanks!
> >
> I think the answer is "it depends". There are some principles that
> apply though:
> - avoid it. If the data changes so infrequently that you're likely to
> restart the app anyway, don't waste effort handling the data as if it's
> something it's not. If it's not critical that users see data that's
> accurate to the moment, don't try to achieve that. Put the effort in
> where it's really needed.
> - abstract it. Whatever the mechanism you use to cache and refresh the
> data, ensure that's hidden behind a façade rather than spread though the
> code that's using it.
> - cache at an appropriate layer. For example, when using hibernate I'd
> simply execute the query every time but ensure the object is in the
> Level 2 cache and that the query is cached.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Best practices for handling code/lookup tables in Struts 2
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Cheng Wei Lee wrote:
> Hi all,
>
> In most web applications, it is unavoidable to have some codes/lookup
> tables, for example, in a form we may need to display the country list. If
> we were to hit the database per request to get this list for displaying in
> the dropdown, it would be too expensive. If we load these values during the
> filter init(), it cannot be refreshed. What would be the best approach to
> handle such scenario?
>
> Thanks!
>
I think the answer is "it depends". There are some principles that
apply though:
- avoid it. If the data changes so infrequently that you're likely to
restart the app anyway, don't waste effort handling the data as if it's
something it's not. If it's not critical that users see data that's
accurate to the moment, don't try to achieve that. Put the effort in
where it's really needed.
- abstract it. Whatever the mechanism you use to cache and refresh the
data, ensure that's hidden behind a façade rather than spread though the
code that's using it.
- cache at an appropriate layer. For example, when using hibernate I'd
simply execute the query every time but ensure the object is in the
Level 2 cache and that the query is cached.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best practices for handling code/lookup tables in Struts 2
Posted by Dave Newton <ne...@yahoo.com>.
--- Cheng Wei Lee <zh...@gmail.com> wrote:
> If we load these values during the filter init(), it cannot be refreshed.
Why not? It's easy enough to create an administrative mechanism that updates
an application-context-scoped data structure. I suppose you run the risk of
having a user with the old data on an "active" form; how dangerous that is
depends on the application and its architecture (but could be handled using
some form of a "dirty" flag).
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org