Rob Nagler wrote: > Stateful instances are also problematic. You have essentially two > paths through the code: first time and subsequent time. If you write > the code statelessly, there is only one path. Fewer bugs, smaller > code, less development.
I find you can tie this cache stuff up inside of your data access objects and make it all transparent to the other code. That worked really well for me. There are hooks for this in some of the O/R mapping modules on CPAN. > Sessions are caches. One of the things Java programmers often do wrong is cache general data in the session, because the servlet API makes it so easy to do. But most data that people cache (as we're seeing in this discussion about search params) is not user-specific and thus doesn't belong in the session (i.e. everyone who searches for "foosball" gets the same result). A session is useful for very limited things, like remembering if this user is logged in and linking him to a user_id. Almost everything else belongs either in separate database tables or in the query args passed on each page. > Oracle will cache the query compilation and results so it is very fast > (basically a round-trip to database server) for the second query. > We execute these two queries on every paged list on every request. Although Oracle can be fast, some data models and application requirements make it hard to do live queries every time and still have decent performance. This is especially true as traffic starts to climb. That's when you can add in some caching and take a lot of stress off the database. There are a million ways to implement caching, from denormalized tables to replicated databases to BerkeleyDB to mod_proxy and most web applications have some data that is read-only or close to it. (I know that yours deals with financial data, so in your case it may actually have to be all real-time data.) - Perrin
