IronEye Announces IronEye Cache 1.0

Discussions

News: IronEye Announces IronEye Cache 1.0

  1. IronEye Announces IronEye Cache 1.0 (5 messages)

    IronGrid has announced IronEye Cache, a tool that allows developers to enable caching for any SQL statement without changes in code. Since it works through JDBC, it works with any JDBC data source.

    Check out IronEye Cache 1.0

    Press Release
    -----------------------------
    IronEye Cache 1.0
    Special Introductory price of $495 for a single license; $695 after June 15, 2003 - Purchase Below

    Performance bottlenecks are often attributed to excessive database calls in an application. Intelligent caching can provide improved performance and scalability, however typical caching solutions can be complicated, invasive, and often times cause more problems than they solve.

    IronEye Cache provides patent-pending "Point-n-Click" caching, and works with any application using JDBC, any database, and requires no code changes. Using a console that shows all of the SQL flowing between an application and a database, instantly select and enable caching on any SQL statement with the click of a button and with no modification to the source code of an application. To ensure the integrity of an application's data, IronEye Cache is a write-through caching solution, immediately committing data to the database when an update occurs.

    In addition to providing an instant caching solution, IronEye Cache enables the developer to conduct what if caching scenarios in the development environment for performance and scalability tuning. It also enables continuous performance through repeated simulations of various cache configurations allowing Java/J2EE developers to determine the caching configuration that will result in optimum performance of their applications. Statistics may also be exported for offline performance analysis.
  2. There are a lot of JDBC caching solutions out there these days.

    Although I understand the attractiveness of the idea of accelerating data-access layer only by switching to new JDBC driver I have many doubts about it.

    I feel that result set caching is very bad idea unless a lot of care is taken to avoid result set cache explosion. This can only be done correctly if database structure (tables and relations) is replicated and cached in JDBC driver. But I am not sure how many vendors really do implement this.

    The right place to put cache at the middle tier or client is in the object model, not in data connectivity layer. Let the database itself cache relational data.

    Regards,
    Mileta
  3. Mileta Cekovic says: "Although I understand the attractiveness of the idea of accelerating data-access layer only by switching to new JDBC driver I have many doubts about it.... Let the database itself cache relational data."

    Although your RDBMS probably has a cache, consider how expensive it is for a client app to get to it. For Oracle (which I've used for 20 years) you need to issue a SQL call, that needs to cross the network (SQL*Net or whatever transport); the SQL statement may need to be parsed - sure, the database caches parsed statements too :). Then the execution plan has to traverse the cached btree index and data blocks buffered in the shared global area to find the row data you need, and transform from record to row format.

    The Oracle SGA certainly helps, but data access even to previously cached data still takes milliseconds, using up precious bandwidth and processor resource at the data server (probably the most expensive piece of your infrastructure). A client or mid-tier cache can avoid that. Programmers can learn to avoid excessive data access; and they can use other approaches like cache enabled CMP when building new apps, but JDBC caches at least make it relatively easy to quickly retrofit a cache onto your own (or someone else's) less than perfect legacy application.

    Horses for courses...
  4. Let me say immediately that I work for IronGrid :)

    Caching at the JDBC level has several benefits. The first is exactly as Nigel describes: anytime you hit the the database, even if you're reading a recently parsed query that happens to be residing in the DB's cache, you're still going to go through a connection step, a parse step, a query plan step, etc. all of which incur a performance cost. The best way to improve database performance is to never hit the database :) Caching at the JDBC level lets us do precisely that.
     The next benefit that I see is in regards to Mileta's point that caching is best performed at the O/R level. Caching at this level takes the "don't talk to the database" to the next logical step, which is "don't talk to JDBC." But it only works if you do, in fact, have an O/R layer in place. The benefit of caching at the JDBC layer is that any application that uses JDBC can take advantage of it rather than the smaller subset of apps that make use of a persistence layer.
       The third benefit is a corollary to the second: since we run at the JDBC layer, we need not (and do not) know anything in particular about your back end db. Whether it is Oracle, or MySQL, or an XML JDBC implementation, we will cache it just the same.

    With regards to Mileta's point about replicating the DB structure in RAM: we don't do this. We, in effect, build a hash map of SQL statements to ResultSets. These hashes then expire after a period of time or are forced to expire by the user on an ad hoc basis.
       The benefit is that it's simple to install and much leaner on system resources (as compared to re-inventing the DB at the JDBC layer). The price is that it implements a "read mostly" scenario, since the cache is unaware of changes in the underlying data until the current cache expires.
  5. With regards to Mileta's point about replicating the DB structure in RAM: we don't do this. We, in effect, build a hash map of SQL statements to ResultSets. These hashes then expire after a period of time or are forced to expire by the user on an ad hoc basis.


    Simply caching result sets can cause cache explosion in some situations. Take a look at the following example (and this situation we had in several projects, so I suppose it could be pretty common).

    Supose there is a need for some sort of searching the database (large tables) using various search criterias. Different criterias and their combinations have different queries that are built dynamicaly at run time. As tables are large (1K-1M records) database could return large result sets. Then you implement some sort of paging UI to that result sets, because of possibly large result sets.

    You need to cache results or you have to repeat the whole (possibly very time and resource consuming) query every time user selects a new page. But you can not cache this at JDBC layer because the same piece of data could be included in many result sets. This can lead to JDBC cache explosion, as we have experienced and then we moved to hand written O/R mapping layer and object caching which reduced the cache size dramatically.

    So, my main concern with JDBC (or any result set caching) is duplicating the same piece of data in many different result sets.

    Regards,
    Mileta
  6. Cache Explosion[ Go to top ]

    Mileta writes: But you can not cache this at JDBC layer because the same piece of data could be included in many result sets... we moved to hand written O/R mapping layer and object caching which reduced the cache size dramatically.

    Excellent point, Mileta, and excellent solution.

    I originally used this caching scheme with a large catalog site which had precisely the paging format you were describing. The way we avoided the explosion issue was to have one main product view that joined everything you could possibly want to know about the product into one long row. Then we would cache that view.
       When we did a paged view, we paged off the id's, then looked up the values for the page in the single cached view.

       Of course, this is essentially the same solution as you're describing: we were caching the data in an "assembled" state rather than in an ad hoc query state. That "assembled" state is somewhat analgous to an object mapping layer :) You've achieved the same thing using a normal O/R tool.