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

It's our forum and we'll cry if we want to etc etc etc.

I did copy it to our developers. and some others outside our company. All I get is Huh ?

If you want to be in the .1% of developers who understand , or are trying to, and you obviously seem like you are, then well done !

For my sins, I work with Marketing data and users and developers a lot.

As Dogbert says "... Fear and a total lack of Comprehension" .. "those of you working in Marketing only need the fear part " ...audience " Why is that ? "

I've been a developer and part-time DBA for 11 years. Still hate java. Gimme Pro*C anytime;

PS My Gruntles are fine; they're in the server room helping out with a SQL*Server problem.

"Andrej Gabara" <andrej_at_kintana.com> wrote in message news:11a3a163.0302280636.2d9ccac4_at_posting.google.com...
> "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 - 09:39:12 CST