RE: Additional Journaling/Commitment Control Info From IBM

> From: Dieter Bender
> 
> breaking it down, we have 270 complex transactions/second on the load
> boundary
> of the system (multiprocessor with 7 cpus in the partition)

With each of these transactions being 50 updates, that's about 13,500
updates per second.  Of course, that's with seven CPU's, and I don't
quite know how to take that into account, but it's a great baseline.

I just ran a simple program that updates 100,000 records in a file.
Nowhere near as complex as what you're doing, of course, but I just
wanted a quick check.  On my little model 270 single-CPU processor (with
370CPW), I managed to update those records in 15 seconds.  That's a
little better than 6500 updates per second.  So we're in the same
ballpark.

This sounds like a great place to do pure performance checking.  Once I
get the bulletin board up and running, I'll extend the test suite and
then we'll see what happens.


> (BTW:
> this problems were solved by changing order by clauses of processes,
> impossible with record level access, very easy with embedded SQL).

I'm not sure what this statement means, Dieter.  Please provide some an
example, and tell me why I couldn't just order my RLA updates the same
way.


> > At the same time, let's still be clear that it's a business
decision.
> > There are costs to be weighed against benefits.  As I pointed out, a
> > system that is mostly static data (few though there are) would
likely
> > not benefit from commitment control.
> 
> and the costs would be very low!!!

True enough <grin>!


> the line is the logical unit of work and nothing else; if its one
record,
> you
> have a commit operation for each record. For the datawarehouse load
> process
> for instance,  one sales detail record is our unit and all database
> operations in the process for this record belong to one transaction.

So in an order, you would update all the A/R and everything, right?  And
in your experience this does not lead to bottlenecks.  One issue though:
from how you talk, it's as if you take a batch file of a million updates
and run it through the machine at one time.  How long has it been since
those records were actually entered?  The reason I ask is that I can see
ways to tune a batch update process.  Does the same hold true when you
have 1000 users entering online orders simultaneously?


> If you cancel the job with *immed, within a transaction, the system
> recognizes
> in the step of completion of the job, that an uncommited transaction
was
> interrupted and does an automatic rollback, in other words: goes back
to
> the
> last completed transaction.
> If the endjob *immed ocurred by pulling off the power plug of the
as400
> (or
> another catastrophy) this will be done at next IPL.

This works when the transaction boundary includes EVERY record in the
unit of work.  You're saying that's how you do it (and I wonder if the
reason you can do that is because of the batch nature of your process -
does it change when you're doing wholly interactive updates?).

What I was trying to say was: If you have more than one transaction per
unit of work and the system crashes between those transactions, then you
in effect have the same problems as if you had no commitment control,
right?  Because what you would in effect have is a partially updated
unit of work.


> But I'm willing to learn!  And since it's really important in the
> > world of JDBC and especially EJB, I think it's important to this
list.
> 
> Joe, sometimes I like to contradict, its important for rpg
applications as
> well, why shouldn't they be (nearly <grin> ) as good as EJBs?

VERY funny, Dieter, VERY funny <laughing>.

Joe