Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Databases Software Programming IT Technology

Load List Values for Improved Efficiency 207

Posted by Hemos from the leaner-and-meaner dept.
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."
This discussion has been archived. No new comments can be posted.

Load List Values for Improved Efficiency More

Load List Values for Improved Efficiency

Comments Filter:

  • You know what's great (Score:3, Insightful)

    by Anonymous Coward on Monday May 02, 2005 @08:00AM (#12405715)
    When telling us there's code... TELLING US WHAT LANGUAGE. It's Java.
    • Reams of java too, though I guess much of that is not directly involved in the caching.

      In persistent perl:

      { #note extra scope
      my @dropdowndata;
      sub whatever{
      #call sub/method unless you already have the cached version.
      @dropdowndata ||= load_dropdown_data();
      }
      }

    • Re:You know what's great (Score:2, Funny)

      by Anonymous Coward
      Thank you so much for telling me this. I would have been completely stuck if you hadn't, I had missed the java headers right at the top of the first bit of code and thought it was ZX80 assembler.

  • Changes to the lists? (Score:5, Insightful)

    by saundo ( 312306 ) on Monday May 02, 2005 @08:01AM (#12405722)
    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.
    • 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.

      • Re:Changes to the lists? (Score:1, Insightful)

        by Anonymous Coward
        "However, if the list data doesn't change very often then there is little point storing it in the database in the first place."

        Really? What about articles on the web or posts here in Slashdot? They almost never change and are usually stored in the database.

        • "However, if the list data doesn't change very often then there is little point storing it in the database in the first place."
          Really? What about articles on the web or posts here in Slashdot? They almost never change and are usually stored in the database.

          It doesn't matter that the content of the articles doesn't change, the whole "list of articles" keeps growing as new articles get posted, hence the need for a database.

          What this article is about is data that doesn't change very ofter (or at all). I

        • Re:Changes to the lists? (Score:4, Insightful)

          by Anonymous Luddite ( 808273 ) on Monday May 02, 2005 @09:22AM (#12406201)
          >> posts here in Slashdot?

          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...
      • Of course, the article leaves one key point unsaid but implied...

        Understand the nature of your data.

        In any system, there's basically three kinds of data:

        -- Static: This is the stuff that changes at a glacial pace, such as state codes, currency codes, and so forth. (for bonus points, put all the static code/description values in a single table with a type identifier for an even larger performance increase at the cost of slightly more complicated code.)

        -- Configuration: This is the data that drives t

      • Re:Changes to the lists? (Score:5, Insightful)

        by orasio ( 188021 ) on Monday May 02, 2005 @10:35AM (#12407103) Homepage
        Well, I develop apps in Java, and of course, apply a caching technique for lists.

        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 /. frontpage.
        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.
      • Furthermore, in most web apps, you're already making a trip to the database on most pages to load data. If your connection is open, the trip to the database to select a small recordset from a table has low cost.

        One feature I love about ColdFusion is that you can cache queries with a time limit. So if you have a busy app, you can cache the query for even 60 seconds and it'll make a difference.

        And yes, I know you CAN do that in PHP and the same with the ADODB library too. (One lib I don't think any php d

      • Data integrity (Score:5, Insightful)

        by coyote-san ( 38515 ) on Monday May 02, 2005 @11:38AM (#12407947)
        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.)
        • I like the problem you give at the bottom.

          Having created an online store application, I have struggled with security issues. If it weren't for those, it would have easily taken 1/2 the time that it did to create the application.

          One of the main things I concentrated on for the back-end db piece was to verify the data that comes in against the DB itself, and it never accepts data from the end user on pricing (whether or not it's in the form or hidden in the form).

          I built the application with two assumptio

    • Re:Changes to the lists? (Score:2, Interesting)

      by Flibz ( 716178 )
      I find that something that helps there, particularly if different users have diferent data for the list is to use javascript.

      Basically, create a session variable for the user (we'll call it cacheTimeStamp) with the current date/time to the hour (i.e. yymmddhh).

      When the page with the drop-down list is called, check current timestamp. If it's expired, create a new javascript .js file & delete the old one.

      Then, when the <script> tag is called, use thecacheTimeStamp value to ensure a current .js fi
    • If you were using .NET 2.0 you could use a database dependency cache model which checks to see if data has been updated every so often, and if it has it flushes its cache and reloads the data.

      Granted, you could also write it in Java, just saying that its readily available in .Net.
      • That and even with .NET 1.0 the solution describe in the article is built-in as well. Application, Session, and Cache collections.
      • FWIW, caching is also built into Hibernate and other ORM solutions for Java.

        I would imagine the benefits of caching would be outweighed by the drawbacks of maintaining a custom caching solution in most cases unless profiling the application has shown that it is absolutely necessary.
    • class Category 'parent IS NULL')
      end

      before_save :invalidate_root_cache
      def invalidate_root_cache
      @@root_cache = nil
      end
      end

      Being that that was a lot of java code, this is an example in rails. before_save marks a method that should be framework-invoked before commiting a change to the database on the categories table (which is introspected from the 'Category' class name, but can of course be overridden). This caches the category list and expires it whenever it may have changed.

      This can of cour
    • not necessarly, you just have to set an interceptor which is triggered once the values are edited and updated... very easy to to, either with direct db related interceptors, application events or aspects...
    • I'm going to have to argue that storing data in static member variables is generally a bad idea. (Of course, so is using scriptlets in the JSP) Excessive use of static variables can lead to unpredictable behavior, and can be hard to debug. Also, syncing the data becomes more complex because of multi-threaded access to the variable.

      While working on high performance web apps where we want to cache the data and prevent having it become stale we genereally to store it in the application context ( ServletContex

  • Huh? (Score:5, Insightful)

    by Renegade Lisp ( 315687 ) * on Monday May 02, 2005 @08:02AM (#12405727)
    Sorry I don't get it. Of course, when you load your data from a cache in main memory, even from within the same address space, you are several orders of magnitude faster than if you make the trip to the database each time. And by several orders of magnitude I mean six to seven orders: you'll easily be a million times faster for a given operation. (A database roundtrip is on the order of tens of milliseconds, while a lookup in a Java hashtable takes mere nanoseconds on typical hardware.)

    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?

    • Re:Huh? (Score:4, Funny)

      by 0x461FAB0BD7D2 ( 812236 ) on Monday May 02, 2005 @08:13AM (#12405769) Journal
      It's because of all the Adblock users out there that we get ads as stories now. The summary even reads like one. Or it's just a slow news day.

      It all depends on how tight your tin foil hat is.

    • Re:Huh? (Score:5, Insightful)

      by computational super ( 740265 ) on Monday May 02, 2005 @08:40AM (#12405914)

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

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

        It's interesting though, that this kind of "revolutionary technique" can be indeed a step forward in the I-don't-know-how-many projects where developers aren't aware of these simple issues. I'm in the consulting business, I've seen them. For them, this kind of consultant might actually be worth the money, and ther

        • Except, this isn't at the "Brightest and smartest" level. This is basic caching. If this was a discussion of the relative merits of linked lists vs doubly linked lists vs hash maps for various different data types, and read/write patterns, we can start thinking best and brightest.

          If it went into a discussion on how to store your data in memory so that the data the application is looking for is probably in the processor cache, we can definitely talk best and brightest.

          Simple caching, however, is basic stuf

          • Except, this isn't at the "Brightest and smartest" level. This is basic caching. If this was a discussion of the relative merits of linked lists vs doubly linked lists vs hash maps for various different data types, and read/write patterns, we can start thinking best and brightest.

            Absolutely agreed. And the things that you mention are those that you'd wish your expensive IBM consultant was capable of. I stand by my statement however, that

            1. there are shops where none of the in-house developers is aw
            • So it's perfectly OK to do things sub-optimally, even if all it would take is a general understanding of the most basic programming practices to make a product orders of magnitude better? "Well, it mostly works, even though it's dog slow." Do you run Windows? :)

              The observation that doing things wrong doesn't always run one's employer into the ground does not magically justify doing things wrong. It's this acceptence of adequecy that's behind the poor state of many things today, but that's a rant for lat

              • Re:Huh? (Score:2)

                by miu ( 626917 )
                So it's perfectly OK to do things sub-optimally

                In the real world of low pay and low prestige IT work it is fairly common for things to be done in a far less than optimal manner. People who know how to do better may just not bother, why make it complicated if it meets the spec - it's not like anyone is gonna give you a cookie if you build an order entry system that is twice the speed they expected.

                At the other end programmers just out of school or training programs may have learned some theory and muc

                • I dunno, I think that acceptance of adequacy may have been fueled by greed, but that the low standards are behind the problem. Greed would exist either way, but it took acceptance of sub-par products to make realization of the greed possible.

                  Larry Wall was right - good programmers have a sense of Hubris, and want to make their programs "right" whether anyone else will notice or not.
    • 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?

  • Oblig. Simpsons Quote (Score:5, Funny)

    by bigtallmofo ( 695287 ) on Monday May 02, 2005 @08:02AM (#12405729)
    "And people, I can't stress this enough. Put your garbage in the garbage can."

    "Garbage in the garbage can. Hmm. Makes sense."

  • Slow news day? Christ. (Score:5, Insightful)

    by Electroly ( 708000 ) on Monday May 02, 2005 @08:03AM (#12405730)
    This just in! Caching frequently-used data yields performance improvements! Film at 11!

  • April Fools... (Score:5, Funny)

    by Kr3m3Puff ( 413047 ) * <meNO@SPAMkitsonkelly.com> on Monday May 02, 2005 @08:03AM (#12405731) Homepage Journal
    Is this April First?

    Wow, next an article about using "for" loops? The benefits of "bubble sort"? "Binary trees"?

  • Well duh! (Score:3, Insightful)

    by AndrewStephens ( 815287 ) * on Monday May 02, 2005 @08:03AM (#12405732) Homepage
    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.

    • Re:Well duh! (Score:3, Insightful)

      by DaHat ( 247651 )
      Be careful with mentioning design patterns like Singletons, you may lose most of the spaghetti code programmers.

  • Done this for years (Score:5, Insightful)

    by Ckwop ( 707653 ) * on Monday May 02, 2005 @08:04AM (#12405734) Homepage
    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.
    • Whats even more interesting is that you are doing it the way it *should* be done in J2EE. Your application object can be equated to the application context or more correctly put the ServletContext object.

      public void doGet(HttpServletRequest req, HttpServletResponse resp) {
      ServletContext ctx = getServletContext();
      // store the data
      ctx.setAttribute("dataKey", dataObject);
      // retrieve the data
      Object dataObj = ctx.getAttribute("dataKey");
      }


      Funny, I never thought I would compliment an

  • PHP-ADODB Caches these queries (Score:4, Informative)

    by displague ( 4438 ) <slashdot@@@displague...com> on Monday May 02, 2005 @08:04AM (#12405736) Homepage Journal
    With ADODB for PHP (and perl http://adodb.sf.net/ [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?]
  • In init(), there is
    ListValuesLoader listValues = new ListValuesLoader();
    but no global.

    However, I can't find the object where the data is actually cached. Is it a Singleton somewhere? Pretty well hidden it must be ..
    • 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.
  • For additional style points, load all lookup tables in one query, and concatenate the HTML into the values.
    But I may be the Kurtz [wikipedia.org] of SQL...

  • Is This Consultant on YOUR Payroll? (Score:5, Informative)

    by rimu guy ( 665008 ) * on Monday May 02, 2005 @08:15AM (#12405782) Homepage

    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 [rimuhosting.com]

    • I have come to expect this kind of thing from IBM consultants. This guy is a 'Lead Developer', and he's writing a Software 101 article, padded with extraneous crap in a likely effort to meet some imposed minimum length.
    • What you wrote there is so underrated, I wish all the people who read this article would hit on your comment and realise that writing good code is more about making it simple and working, than it is to use all the latest, coolest, make-me-seem-clever crap that we have to put up with nowadays.

      And, to realise that those consultancies charge a large amount of cash because their developers are crap and produce this over-engineered rubbish. (and is another reason why all those large-scale government projects th
    • I question his experience. He would have a hard time interviewing in my shop using that code for a few reasons.
      • Using static variables to store global data instead of the ServletContext
      • Using Vector instead of ArrayList
      • Using a Hashtable instead of a HashMap
      • Magic strings

      P.S. Before you mention synchonization remeber as of Java 1.2, to get a synchronized Map (in place of Hashtable) or List call Collections.synchonizedMap(map) and Collections.synchronizedList(list).

  • GoF Decorator pattern is better for this task (Score:5, Insightful)

    by MarkEst1973 ( 769601 ) on Monday May 02, 2005 @08:16AM (#12405788)
    Assuming one writes a well-factored application, I believe Decorator makes a much better caching mechanism that what the article presents.

    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)

    by Tim C ( 15259 ) on Monday May 02, 2005 @08:18AM (#12405798)
    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.
    • Absolutely. I've been meaning to write an article on this (in my near-infinitely long queue, after the stuff that pays real money). The problem is that many web designers (esp. those without other programming backgrounds) learn the beauty of storing data in databases and they become overly enamoured with it. Databases are appropriate for many web applications but if you're hitting the database to, for instance, draw your home page, you're going to beat your server to death and your viewers are going to see
      • No offense, but a lot of this sounds like poor advice.

        Firstly, a lot of your caching solution should depend on what tools or language features are available for the language you're using to implement your site. For example, advocating caching things to disk isn't really necessary when you're using Java since it's more effective to use in-memory caches. If you use an ORM solution like Hibernate, caching happens behind the scenes and you don't even have to think about it. However, if you're using a script
        • With all due respect, I think your reaction is little bit knee-jerk on this. While, as it is often stated, there is no silver bullet and there will definitely be places where this is inappropriate, there are quite a few areas where it will work nicely. I'll be the first to admit I'm fairly naive when it comes to Java Server's caching capabilities (I'm more of a php / perl / shell scripting guy).

          Serializing data to the disk is a good suggestion in many cases. Perl is fairly rich in this area, however, PH
          • ...however, PHP (far more popular for web development, especially with less experienced programmers) is not. It has a serialize to string function, however, this is not terribly useful if you have several variables (unless you want to deal with delimiting the variables, making sure the proper character(s) are escaped, and then unrolling that later).

            Why would you bother with delimiters when PHP is perfectly capable of serializing arrays/hashes. Just dump all your variables into an array and serialize. Th

  • Memcached (Score:3, Informative)

    by captainclever ( 568610 ) <rj@audioscrobblCHEETAHer.com minus cat> on Monday May 02, 2005 @08:27AM (#12405843) Homepage
    Or you could use something like Memcached [danga.com]. Works with pretty much any language, and tonnes less hassle. (Thanks LJ ;))

  • News? (Score:3, Funny)

    by Baavgai ( 598847 ) on Monday May 02, 2005 @08:30AM (#12405855) Homepage
    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...
  • Yes, it's obvious to anybody with half a brain. But from the looks of several apps out there, there's a LOT of coding being done by the lower half of the bell curve:
    • One very old 200,000 line app, written in assembler, that could only ever run on one particular CPU, had a #define for the number of bits in a packed character field (6 bits BTW).
    • One really losing Java app does about a bazillion (200+) separate SQL queries to ask for things that have not changed in 50 years. Funny, the app runs slowly, ev

  • And for the follow-up article... (Score:5, Funny)

    by azuroff ( 318072 ) on Monday May 02, 2005 @08:33AM (#12405869)
    ...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.

  • ...caching (the subject of the article) are the three fundamental algorithms, so it was told to me by a little bird.

    of course, i immediately made a base case, trapped the fowl and filled my belly (to put into practice such sound advice, you see ;-). mmmm, cs stew...

  • Any web developer who'se picked up a book for PHP/ or NET Web Development would know how to do this in Apache or IIS.
  • What's the point of all these fancy new RAID arrays and such if we developers can't get increasingly sloppy with our coding practices?

    Though I kid, I find that populating drop-down boxes for applications are pretty minor in the grand scheme of things. My performance issues tend to stem around doing cross-server database queries involving tables with millions of rows. That's when things get slow.

    I'm sure there are some people who have to do this level of optimization - folks like Google and Amazon.

  • What's your Vector, Victor? (Score:3, Insightful)

    by Vengeance ( 46019 ) on Monday May 02, 2005 @08:59AM (#12406018)
    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.
    • There's the use of Hashtable; the non-thread-safe singletons; the traversal of the entire lists in ValidValuesTable.getOption; the unnecessary storing of the options and values string-arrays; the failure to pre-size the ArrayList; the fact that DropDownItems aren't immutable and, my favourite (repeated several times throughout the code):

      private void loadStatusList() {
      Hashtable obj_Hashtable = new Hashtable();
      ListValuesDAO listValuesDAO = new ListValuesDAO();
      obj_Hashtable = listValuesDAO.getListValues

  • Wow! What amazing breakthroughs Web developers come up with! Why, soon there might be a good way to maintain client-side state for Web applications. What I will coin as "client-side applications" could provide endless opportunity for rich, dynamic user interaction. These "client-side applications" could even do their own processing and have storage from the local host. If only there were some type of, what I'll call, "socket" to maintain a persistent data connection for protocols designed to fit the needs

  • Externalize Picklists... (Score:3, Insightful)

    by zettabyte ( 165173 ) on Monday May 02, 2005 @09:40AM (#12406444) Homepage
    He should be externalizing the picklists to a .properties file. He'll get the caching through Properties and the strings will be ready for localization.

    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:
    1. Hungarian notation is NOT necessary in Java. Period. End of story.
    2. No one uses Vector anymore.
    3. There are some nice tag libraries, so STOP PUTTING JAVA CODE IN JSPS!
    If you're a code monkey, memorize these two quotes:
    Increasingly, people seem to misinterpret complexity as sophistication, which is baffling - the incomprehensible should cause suspicion rather than admiration. - Niklaus Wirth
    and
    ...it is simplicity that is difficult to make. - Bertholdt Brecht
    (quotes from http://www.vanderburg.org/Misc/Quotes/soft-quotes. html [vanderburg.org])
    • No one uses Vector anymore.

      Why the hell not? Is it uncool now? Do I need to stop using it for l33t status?

      There are some nice tag libraries, so STOP PUTTING JAVA CODE IN JSPS!

      One might argue it is easier to read especially for something simple.

      Are you one of those types that spend all thier time critizing other people's code just because it is not how they would code it? I hope I never work with you.
      • 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);
        }

      • There are other responses above mine which better address your questions/disagreements. My responses below are meant to be humorous and/or obnoxious, depending on your perspective.

        Why the hell not? Is it uncool now? Do I need to stop using it for l33t status?

        Yes. It's uncool. If you wish to be 1337, you need to stop using Vector. Only \/\/4|\|k3rz use Vector. At least that's what they told me in my Java class at DeVry(1). ** braces for DeVry graduate flames **

        One might argue it is easier

    • that's the only reason I've used Vector, aside from the minor synchronization distinction. Why doesn't ArrayList have setSize()? Anyone know this?
  • Come on. How can you call this concept even novel. Too much data to load from a slow process, so load it up front and cache it. I don't think you could call yourself a geek if you haven't bumbled into that one.

    Come on guys, you can do better than this!
  • I agree with other comments. This is pretty basic, but then again you can't beleive some of the stuff people do SQL queries for. I started at one job, took over a web app that had a lot of forms with a "STATE" drop down. Every time they were going to a ref table to build the drop down. I gave them unbelievable crap.. "when's the last time we added a state to the U.S.?"

    The point of stuff like this is, you can keep a dynamic page to generate the html and just make the damn thing an include. You can always r
  • The guy who wrote this just wanted to show a nice concise summary of different things you can do to cache static data on startup but still keep it in a DB.

    So please direct all flames (A) to whoever posted this as "News", and (B) to whoever accepted this "story".

    Or perhaps Hemos said to himself "Damn, a lot of sites sure are slow latley. Perhaps they know not of caching." and then posted the story.
  • The number of database hits isn't the whole story, and is really not all that important. My web+database apps are LAPP driven, which provides some help with caching frequently used data (such as drop down lists).

    Linux uses all otherwise unused memory for file caching. My database machines are loaded with 3-4GB of RAM each, so there is lots of memory used for caching.

    PostgreSQL uses shared memory caches to increase performance (though I don't know the exact nature of its shared memory usage), and it work
  • You'd be surprised what a novel concept this is to a lot of web developers. Particularly ones that came from other languages and learned web dev on the job. A directive like this coming from IBM may actually penetrate the thick COBOL* muddled minds of a lot of less than stellar developers I've worked with.

    * feel free to substitute VB here, as I've worked with young programmers who only learned VB in college for whom this approach is beyond their comprehension. Their normal solution is "More RAM".

  • Rule 1: Never do anything you don't need to. (run time optimization)
    Rule 2: Never do anything twice. (cacheing)
    Rule 3: Empty cache that won't be required. (space optimization)

    If you design properly, your software will run fast, stay fast and small.

    Remember "Dr. Dobb's Journal of Computer Calisthenics and Orthodontia (Running Light Without Overbite"?

    Its just as true now as it was back when you were writing for machines with K (not M) of RAM.
  • With Smarty [php.net], and PHP, you could put the list in its own cached template. Check to see if the template is cached before displaying it and if not go to the database.

    You can even use Smarty's html_options function to build your lists for you.

    And when something changes the data for the list, just clear the cache. The next time it's needed the cache will be updated.

  • ...that can be automated.

    For instance, on some sites that I've developed, whenever an admin page is used to add to menus, it *does* update the DB, but it also recreates a static .php file that has the menus as .php code, and that file is included whenever the menu is used. No database access for pages that need the menus, no restarts necessary whenever the semi-static data is modified. Pretty much a win-win for all involved.

    Or did I miss the point of the article?
  • For this to be a useful optimization, you have to have a web page where 1) the web page really has to be generated from a database, 2) the options for the SELECT vary enough that they need to be retrieved from a database, 3) the specific page is loaded enough that cacheing is helpful, 4) the number of different pages with this issue is moderate, and 5) traffic is high enough that any of this matters. That combination isn't all that common.

    The more likely situation is that the Java fanatics got carried awa

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close