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

Noons wrote...
> warning: long and boring techo-design stuff follows...

Shorter, but still possibly boring stuff follows :)

> Define business logic before you start placing it.

Could not find a good definition on the web, so this is what I think of it. Business logic is:

(1) A transaction driven by a use case that makes changes

    to application data.

    Example: A user opens up a project, looks up his task,

	and sets the task state to "completed". The business logic will
	change the task's state to "completed" and updates any
	dependent tasks, setting those to "ready".

    Let's call that transactional business logic.

(2) A query that calculates information that is not immediately

    apparent from the data itself - it takes some work to     calculate that information.

    Example: Application suggests to a manager what     people will fit to work on a given task and fitting     a specific skill, as well as some other rules.

    Example: Use case: Show a user what his active     tasks are, ordered by due date and priority.

    Let's call this one computational business logic.

My concern is on (1), because it causes objects in a cache to become invalid. I don't worry about (2). Also, I'm talking only about caching object states, not caching any calculated data. Some of (2) can be be done just by a simple DB query, which could bypass the cache.

Do you agree that (1) is a problem for effective caching of those java objects? The problem is with stored procedures that update data in the tables affecting cached objects, without being obvious to the app server what those changes are when calling the stored procedure.

For a business logic case like (2) a stored procedure would probably outperform Java, because the stored procedure is always closer to the data it is accessing. And a lot of those accesses can be multiple complex queries.

So, I think using PL/SQL for (2) can be a good thing, but for (1) it may not be, because of cache coherency. But if most objects are cached in the app server and are valid, then Java for case (2) could also outperform PL/SQL; this also has the advantage that a developer can work with the object model and not the data model. That is why I favor a model where most business logic is implemented in Java and none or very little in PL/SQL. To be able to take advantage of an effective java object cache, you have to make good decisions of where you put the business logic.

What do you think?

-Andrej Received on Wed Feb 26 2003 - 10:15:03 CST