When you talk journaling here are you talking about database journaling as in STRJRNPF? Since the first day we had our first S/38 we have journaled every file except some temporary work files. Isn't that a fairly common practice? And isn't the default for any table created via DB2 SQL to have journaling on?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Thursday, August 20, 2009 10:37 AM
To: Midrange Systems Technical Discussion
Subject: Re: Modernizing applications (was: Explaining single level store to non ipeople)
Lucas,
After some off-line discussion with another list member and some research of my own, and also because of your reply, I'm convinced that SAP does do some form of journaling, and would now be very surprised to learn otherwise. And that would partly explain the higher throughput I'm getting. I'm not journaling. I'm not using commitment control - in this case.
On the other hand, as I explained earlier, my order entry application creates an order, then creates one or more line items, individually. Users press enter, a line item is created, the item is added to a table on the screen.
After users exit "add" mode, they may select multiple line items to change, and enter a cycle where each line item is pulled up individually on the screen, and changed individually.
I understand that other developers may use a different model where multiple records are entered or changed as a batch, then eventually posted as a batch, but I don't use that model, and wouldn't recommend it either.
However, I'm planning on using commitment control on my next application - GL Journal Entry, to ensure that debits & credits balance (meet ACID requirements).
HTH,
Nathan.
----- Original Message ----
From: Lukas Beeler <lukas.beeler@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, August 19, 2009 11:19:10 PM
Subject: Re: Modernizing applications (was: Explaining single level store to non ipeople)
On Wed, Aug 19, 2009 at 23:22, Nathan Andelin<nandelin@xxxxxxxxx> wrote:
use full commitment control and journalling for everything
It would really surprise me if SAP's benchmarks included journaling.
They do. tlogs aren't optional in other RDBMS. Except in MySQL with
MyISAM tables, which is a special case.
But my order entry applications follow a traditional header-line model, where the order is entered, then a series of line items are entered. Each entry adds or changes a record on the server, immediately.
And there is never ever any need in your application to change more
than one row at a time?
Under my header-line model, there's no need for commitment control. But RPG-based commitment control doesn't add much overhead, if or when needed.
Well, i don't see ACID in a business critical application as "optional".
Well, I subscribe to the old adage - make everything as simple as possible. In this case, the IBM i HTTP server forwards browser requests to an RPG-based server which natively interfaces with the database, then returns an HTML/JavaScript response.
Yep, but "Notepad is faster than Word" is hardly news. Even if the
machine running notepad is slower.
midrange.com
