--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family. Remove the negative part, keep the minus sign. You can figure
it out.
"Andrej Gabara" <andrej_at_kintana.com> wrote in message
news:11a3a163.0302260815.92ac9b6_at_posting.google.com...
> 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.
Why cache this? It make no sense. Just read it from and write it to the
database. Your "intelligent" caching of this stuff is making spagetti out
of the whole thing. It is WAY more complex than it needs to be.
Someone must be on some open ended consulting dollars or working in acedemia
(with no experience with the real world)
>
> (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.
>
Not at all. Why cache it? It just complicates life and gains you nothing.
The only time I've see something that worried about whether the data
underneath changed at all or not was to have a seperate table where each
user "registered" their interest in stuff. It can't be too generic, but
worked something like this:
Each row in the table was a currently logged in user.( users had to be
unique or how do you tell them apart) Each pair of columns had a primary
key from someother table and a counter. Also at the "end" of the table was
a master counter. So let's say it was a HR application and you want to know
if any of the pay records changed. Lets say you have an employee table with
ssn as the pk and a pay table with ssn and date_paid as the primary key.
Your interest table would look like:
user_name pay_ssn pay_cnt master_cnt
jimk 111-11-1111 0 3
tom 222-22-2222 4 7
Let's say George updates the pay for our employee who's ssn is 111-11-1111
then the interest table would look like:
user_name pay_ssn pay_cnt master_cnt
jimk 111-11-1111 1 4
tom 222-22-2222 4 7
So all Jim's session keeps track of is the cnt columns. Periodically Jim's
session looks at the master_cnt and sees if it changed. if it did then it
requeries all the cnt columns to see which one changed from what he saw
last. Then he knows which item of interest changed and he can requery that
item - in this case pay. You could do something with dbms_alert package
also and threads in Java so you wouldn't really have to poll, but the query
is small. How does the cnt columns get uppdated? You have after change
triggers do the updating. They only update the primary key part.
Jim
> 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 - 20:05:56 CST
