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."

Comments

PHP-ADODB Caches these queries

[displague]

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?]

Re:Changes to the lists?

[AndrewStephens]

An excellent point, the article assumes that the data will not change very often, if at all. However, if the list data doesn't change very often then there is little point storing it in the database in the first place.

Not to say that the article was actually bad or anything, its just a little light on when you would want to use this, and what some of the problems with this approach are.

Is This Consultant on YOUR Payroll?

[rimu guy]

If you have yet to read the 25-page FA, may I present the precis:

Database hits are expensive. Reduce them where possible. For example, cache static lookup data.

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

Re:Externalize Picklists...

[philipborlin]

There are very good reasons not to use Vector. The main one is that it internally synchronizes all calls. Any algorithms 101 class will show you why that is a false sense of security.

The classic example is:
vector.size();
vector.get(0);

Each one of those calls is synchronized internally but the JVM can still switch threads inbetween the two calls causing a race condition. To make that code thead safe you need to synchronize externally:

synchronized(vector) {
vector.size();
vector.get(0);
}

Now the code is thread safe but there were three synchronization calls (our explicit call and one for size() and one for get()). Very inefficient.