Slashdot Mirror
Load List Values for Improved Efficiency
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."
When telling us there's code... TELLING US WHAT LANGUAGE. It's Java.
Interesting article, but preloading those values will invariably lead to out of sync conditions when the backend changes. Nothing mentioned in the text as to how to cater for that eventuality.
-- The problem with troubleshooting is that sometimes trouble shoots back.
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?
"And people, I can't stress this enough. Put your garbage in the garbage can."
"Garbage in the garbage can. Hmm. Makes sense."
I'm a big tall mofo.
This just in! Caching frequently-used data yields performance improvements! Film at 11!
Is this April First?
Wow, next an article about using "for" loops? The benefits of "bubble sort"? "Binary trees"?
D.O.U.O.S.V.A.V.V.M.
Keeping frequently used data in static singletons, who would have thought it!
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.
sheep.horse - does not contain information on sheep or horses.
Well thank you captain obvious.. I've been doing this for years with ASP. Just load the contents of the listboxes into the Application object.
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.
With ADODB for PHP (and perl http://adodb.sf.net/, you can call CacheGetAll, CacheExecute, etc... The query resultset is saved to a temporary file. This avoids having to create the cache within the same function you would normally call without having to write extra code.
[first useful post?]
Marques Johansson
If you have yet to read the 25-page FA, may I present the precis:
The simplicity of the point however is lost in the complexity of the article. It covers web.xml settings, servlet classes, list value loaders, persistence backends for said loaders, data source 'helpers' for said loaders, custom object classes for the loaders, several subclasses for said object classes, and a jsp page (to boot). Phew.
The author refers to this design as a quick and easy approach. It is not. If you are not familiar with Java and read this article, please do not be put off. He could have demonstrated the point with a far simpler example. E.g. static variable, sql statement, jsp code, done.
[The author] has worked with IBM Global Services for one year, and has five years of experience in J2EE-related technologies. And it shows. I dread to think how much a fully realized IBM Global Services project would cost should all its consultants apply this sized sledgehammer to each small task. Hopefully the article was not written up on the client's dime as well.
--
Java Hosting
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).
It's called caching, and it's been done since people had to load in commonly-used external references.
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.
It's official. Most of you are morons.
Or you could use something like Memcached. Works with pretty much any language, and tonnes less hassle. (Thanks LJ ;))
Last.fm - join the social music revolution
Seriously, I've you're into servlets and you haven't been caching non dynamic data, shame on you.
By same token, if you're on of those twits who caches five years of data warehouse information in the application layer, there's a special place in programmer hell for you...
...this "Lead Developer" at IBM will discover the wonderful performance benefits of pooling database connections, rather than open a new connection every single fricking time he hits the database. No wonder he saw a massive performance increase when he learned how to cache the lookup values.
And what's up with the "obj_" prefixes in some of the code listings? Newsflash: Java is an object-oriented programming language, and most competent Java programmers can figure out that a variable called resultSet probably isn't a primitive. You don't need to waste another 4 characters pointing out that fact.
After bracing myself with some more coffee, I read a bit more of this article.
Bad, bad, bad.
What's with the Vectors, anyway? I haven't used those in years.
It was a joke! When you give me that look it was a joke.
The individual list types are all implemented as singletons.
That is, they have static 'getInstance' methods, maintain private static references to their own solitary instance, and have private constructors.
This is a very standard OO pattern, and seems to be one thing the article got essentially right.
It was a joke! When you give me that look it was a joke.
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
Thanks for the hot tip... I'm really anxious to see how the world changes now that the concept of the cache has finally been brought to light. Behold, sarcasm, I've invented sarcasm! Wow, maybe we should create a /. article for me?
The reason you would maintain "static" data in the database is for data integrity.
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.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken