Re: (long) Sniffing redo logs to maintain cache consistency?

"Telemachus" <tollg_at_tendwa.rns.net> wrote in message news:<Uen7a.12163$V6.16434_at_news.indigo.ie>...
> I have to say that post should be stapled to developers foreheads ...

Ha :) That statement is almost as funny as

   >>That was a relatively "I'm on your side" post from Sybrand<<.

You're blessed by being naturally funny.

> I'm going to copy it to a couple of our [developers] who are thinking about
> this kind of thing.

Maybe talk to your developers. Ask them why. They obviously aren't happy with the existing architecture. Don't just think they need to learn from you. (Unless you only have newbie developers, or developers who cannot think straight due to infections caused by staples in their foreheads).

Ok, now to Nuno's post. Thank's for making the effort of explaining. And I agree with you, performance-wise this is a good idea. Our architecture is pretty much that as well. So, we've been there too. And we still are there. And I cannot argue against what you've said, except for bubbling "cascading" events to the user, and possibly have lots of stale-data errors: It's not something users appreciate. They don't consider it a warning, they consider it a bug if the app server caches stale data and they just wasted a few minutes for having filled out a form and pressing the "Save" button, just to click on a "Refresh" button so they can redo their typing.

Let me back up... my initial post on sniffing redo logs was way too specific. And it obviously rubbed people the wrong way (and for the right reasons).

Here are some problems we are facing, and probably all that use the session facade plus DAO pattern:

(1) One of our customers installed our app server and noticed it's using

    *only* 300MB in production. He asked us what he can configure in order     for our app server to use the 4GB of memory that is available. [Nowadays,     a new server box ships with that much ram]

    We do cache read-mostly data already. And that's not that much. Some     cache consistency issues there, but we get by with timeouts and validation     queries. But this kind of data does't take up much space.

    We don't cache any transactional objects because of cache coherency     problems.

    So, obviously times have changed. Memory-conservation is not really an     issue any longer. It's the opposite. The question is what can you do to     take advantage of this extra memory. Why conserve resources when there     are plenty available and you can take advantage of it?

    The answer seems to be to cache more transactional data in the app server.     And if that duplicates some of the work the database is doing, that's     ok! The customer doesn't mind if the app uses caching effectively to     improve performance and reduce load on the database, even when     some work is duplicated that the database is so good at.

    And you can tell that times are changing. There are products coming     out to address this. Persistence's EdgeXTend 2.0 O/R distributed cache.     Oracle OC4J. Hibernate O/R mapper that supports JCache (however, not     distributed) - open source even. They all want to take advantage of     this free memory that is available.

    Those solutions may have been a bad idea 5 years ago, but memory is     becoming very cheap. Question is how do you take advantage of this.

    Maybe disk i/o isn't much of an issue any longer with databases. With     a huge memory, the database has a lot cached anyhow. So now network     latency from app server to database is becoming a bigger factor.     The database is very smart of using the cache and query plans to     minimize disk I/O. But what component does exist that minimizes     network I/O plus JDBC serialization overhead from app server to database?

(2) Another issue is developer productivity. The DAO model makes it very

    simple to implement the data access layer (as Nuno calls it). However,     those objects are pretty dumb. Don't know about relationships, etc. It's     basically wrapping a record of a table into a Java serializable object.         

    This form of data access layer performs pretty well, that's true. But     that's because it pushed complexity to the layer above. And if there is     no layer above, it's up to the developer having to deal with that     complexity when implementing business logic. The developer of course     wonders what model would help him do his job more effectivly.

    So, don't staple news posts on developer's foreheads... instead, try     to understand their pain. It will make you more likeable.

    To me, DAO is a design pattern that addresses performance. It doesn't     exist because it is oh so elegant. Eventually the time will come and     this model is a thing of the past.

    Ok, maybe I'm too optimistic and reality hasn't changed quite yet     in favor of looking for a better model. But I'm not the only one. Entity     beans exist for that reason, and I am aware that they are rejected     because they don't perform (for other reasons too). But maybe there     is something else?

In the end, it's not the design with the highest performance that wins. It's the most elegant design that solves critical problems and has acceptable performance. Over time, the thinking of what is acceptable performance changes because cpus run faster and memory gets cheaper.

Please no impolite replies from disgruntled Oracle DBA's, please! If you have time to waste, go rebuild an index or whatever.

Thx
Andrej Received on Fri Feb 28 2003 - 08:36:40 CST