Load List Values for Improved Efficiency 207
An anonymous reader writes "Reduce the number of database hits and improve your Web application's efficiency when you load common shared list values only once. In this code-filled article, learn to load the values for drop-down lists when your Web application starts and then to share these loaded list values among all the users of your application."
You know what's great (Score:3, Insightful)
Changes to the lists? (Score:5, Insightful)
Huh? (Score:5, Insightful)
What's the point? Since when is Slashdot a forum for random tech tips (and not very thrilling ones at that)? Did IBM pay to get this posted? Is Slashdot trying to make fun of IBM by actually posting it?
Slow news day? Christ. (Score:5, Insightful)
Well duh! (Score:3, Insightful)
Seriously, this is probably good advice for someone just starting out programming, but I would expect anyone with any experience at all to know about this. Its hardly a revolutionary new technique.
Done this for years (Score:5, Insightful)
In ASP.NET you can even do cache invalidation when the database changes. Simply create an extended stored procedure that's fired when any of you update/insert producers run that write to the changed record ids to a Queue (using Microsoft's Messaging and Queuing service) then have a thread in the ASP.NET process that periodically check the queue for new messages and clear the values that have changed out of the cache.
Because the Queuing service works across networks it's a really neat way to provide scalabity in web applications - if you can't wait for SQL 2005 which will provide cache invalidation on database updates as standard.
Simon.
Re:Changes to the lists? (Score:1, Insightful)
Really? What about articles on the web or posts here in Slashdot? They almost never change and are usually stored in the database.
GoF Decorator pattern is better for this task (Score:5, Insightful)
A Data Access Object should have 1) an interface (defining add, remove, retrieve, etc.) and 2) a standard implementation of the interface that reads/writes to the database on every method invocation.
A Decorator can implement the data access interface, delegating all method invocations to a wrapped instance of the standard implementation. Decorate the behavior of the standard impl. by providing a cache, checking the cache before retrieving a model and updating the cache before saving a model.
Because the standard impl. and the decorator share the same interface, you can have a factory create instances for you. Your code doesn't know or care which instance it is using. Mix and match Decorators to your heart's delight. A logging Decorator (track what data is being access, etc.) can be thrown into the mix, and again your calling code wouldn't be the wiser.
This pattern is easily unit tested and load tested. It doesn't require a running web container to test or run. It Just Works(tm).
Well, duh (Score:5, Insightful)
I've not RTFA, so perhaps it's truly excellent, but why the hell has this been posted? Anyone who's writing any sort of application and not making intelligent use of caching is either really junior, or should probably be looking for a new job.
Re:You know what's great (Score:1, Insightful)
Should I agree with the concept, it's then up to me to implement the solution in my favorite language.
Re:Huh? (Score:5, Insightful)
I think you're being FAR too polite here, sir. Feel free to drop in an occasional, "Are you f-ing kidding me with this drivel?" in your critique of this type of ridiculously simplistic and obvious article.
On the other hand, there's a good take-away here. If this "revolutionary technique" was so mind-bending to IBM consulting services, I know where I won't be spending my consulting dollars...
What's your Vector, Victor? (Score:3, Insightful)
Bad, bad, bad.
What's with the Vectors, anyway? I haven't used those in years.
Re:Well duh! (Score:3, Insightful)
Re:Changes to the lists? (Score:4, Insightful)
Apples and oranges.
You're talking about adding items (posts) to a recordset (slashdot thread). The items are static but the recordset is not. It changes frequently.
The caching they're talking about involves a recordset that seldom changes, and would therefore be suited to storage outside a database and rebuilt as it changes - IE one trip to the database per change rather than one trip per view. This wouldn't make sense with something like a slashdot thread where records are added non-stop...
Externalize Picklists... (Score:3, Insightful)
If the picklists are at all updateable while the application is running, he can cache as he does, but he'll a mechanism to invalidate the cache and re-read from the database.
Forgetting that for a moment:
- Hungarian notation is NOT necessary in Java. Period. End of story.
- No one uses Vector anymore.
- There are some nice tag libraries, so STOP PUTTING JAVA CODE IN JSPS!
If you're a code monkey, memorize these two quotes:and
(quotes from http://www.vanderburg.org/Misc/Quotes/soft-quotes
Re:Changes to the lists? (Score:5, Insightful)
My data does change, but I store it in a tree.
When someone changes a dropdown, I just erase the cache. When someone wants the list, it gets refilled. All of it is safely synchronized.
Of course, I don't believe it's worth an article, and I don't believe it belongs in
IBM developerworks is a nice source of information when you want to program the mainstream way. It's good for teams, because it makes easily understandable code. Of course it's boooring and not news, though.
Re:You know what's great (Score:4, Insightful)
If you take your example of codes in a file, how will you distribute it? How will you maintain it? How can multiple users access it? What happens if someone accidentally deletes it?
Databases are designed to solve exactly these types of problems.
You need to have the One True Copy of the data, in all cases. If you wish to distribute a flat-file or marked up copy of that data provided it's completely static aside from a software revision, then that's fine. But keeping key data unprotected -- or worse, opening up yourself to multiple masters -- demonstrates to me that you're thinking about things at the hobby/toy project level, certainly not at a distributed or COTS level.
Your data is your application. It doesn't matter if the data is static or not. And for goodness sakes, if you're going to be using a database anyway for the dynamic data, eat the storage and keep the master copy in the freaking database!
(And if you're not using a database at all, well, that's further evidence to me that you're thinking at the toy/hobby level of project scope.)
If you were going to store large, binary data sets (such as video) in a database, I'd tell you to use Oracle and either store the data out-of-line with BFILEs, using the database as an indexing mechanism, or store it in the data as BLOBS, depending on whether access time (use BFILES!) or recoverability (use BLOBS!) was more important. I don't know what that project used, but writing either of the apps with those data storage concepts is pretty trivial.
Data integrity (Score:5, Insightful)
For instance, the list of US states and Canadian provinces does not change very frequently. I think the last Canadian change was about a decade ago, the last US change nearly 50 years ago.
The "full name, abbreviation" name used in most pulldown lists (full name as label, abbreviation as value) can obviously be considered static.
So why keep it in a relational database? Simple - you can use it to provide referential integrity for all "state" fields in the rest of the database.
This isn't a huge deal with states, but it can be very important with domain level enumerations. Your form actions may be well-behaved, but a robust system must account for clowns who feed their own data directly into your action URL.
(As an aside, this isn't a theoretical problem. I've heard stories of people getting an order form for, oh, a laser printer. They capture it, change the price of the printer from $499.99 to $49.99 and submit the order. The action accepted it, and when the company attempted to refute it they lost because it was considered a bona fide negotiation since the web site could/should have been programmed to reject forms with altered prices. They made an offer, the client made a counteroffer, and the company accepted it. This depends on your state, etc. Given the current political climate I wouldn't be surprised to learn that this is now considered computer fraud with a 10 year prison sentence.)
Re:Externalize Picklists... (Score:3, Insightful)
No, it is I who hopes to never work with you. I would clearly be out of my league and unable to keep up, what with having to use design patterns like MVC to help me remember where to find code that I have (and even have not) written.
Yes. I am. I'll give you an example.and (1) I have nothing against DeVry graduates or their skills. I don't know any DeVry alumni, nor have never worked with anyone having any affiliation with DeVry. I'm merely making a joke.