Re: best practice for web client updates to multiple tables

[J Franz <franz400@xxxxxxx>]

Mike & Charles:
 
When I mentioned " couple tables hold the working order " - these
are not the 11 final files updated (other than to say the working
or pending order is now processed).
I agree the commitment is only after all data is collected,
and no further user waits.
I'm not certain of the tooling they are using, but agree 
100% about updating through commitment
Jim
 


________________________________
From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> 
Sent: Tuesday, December 31, 2013 4:03 PM
Subject: Re: best practice for web client updates to multiple tables


Mike has a point,

A proper transaction should have no (user) waits between each piece.  You
should be collecting the pieces temporarily, either in the app or in a set
of "temporary" tables use just for that purpose.

When the user is done, you start the transaction and update your regular
order processing tables using commitment control.

We have an extranet site that works exactly this way.  The app writes out
to a cart table without commitment control (since it's just one table) as
users enter items and when the user submits, a transaction is started and
our order processing tables are updated and the cart table cleared of that
users items.  Assuming no errors, the transaction is committed.

Charles


On Tue, Dec 31, 2013 at 3:44 PM, Mike Cunningham <mike.cunningham@xxxxxxx>wrote:

> This statement "The failed updates could be time-outs, user cancelling
> session (after long delay), or logic halt in client (they are working on
> identifying those)." Makes me wonder if the way the web side is designed
> does not lend itself to benefitting from commitment control. If the web
> client is stateless and is updating a couple of these 11 tables for each
> item added to the order, then waits for more items, then the user has to
> finalize the shipping info which updates some additional tables and then
> provides payment info which updates a few more, I don't think a "begin
> commit" then the first item is added and an "end commit" when payment is
> done would work.
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
> midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of J Franz
> Sent: Tuesday, December 31, 2013 3:20 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: best practice for web client updates to multiple tables
>
> Charles,
>
> Your point is well made.
>
>
> Jim
>
>
> ________________________________
> From: Charles Wilt <charles.wilt@xxxxxxxxx>
> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Sent: Tuesday, December 31, 2013 2:52 PM
> Subject: Re: best practice for web client updates to multiple tables
>
>
> you need a better C# developer...
>
> Actually, I'm shocked that they wouldn't have originally written the app
> using transactions in the first place.  Which would have meant coming to
> you with a "why are we getting SQL7008 - Table not valid" since the tables
> aren't journaled.
>
> While I can't say I've used transaction in C#, I have used them in Java.
> It's not that big a deal.
>
> Start journaling on your tables, then tell the C# guys that their app needs
> to use transactions.
>
> Charles
>
>
> On Tue, Dec 31, 2013 at 1:27 PM, J Franz <franz400@xxxxxxx> wrote:
>
> > <quote>Why do you think commitment control is a larger effort to
> > implement?</quote>
> >
> > That was a comment from the C# developer.
> >
> > Jim
> >
> >
> >
> > ________________________________
> > From: Charles Wilt <charles.wilt@xxxxxxxxx>
> > To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> > Sent: Tuesday, December 31, 2013 1:21 PM
> > Subject: Re: best practice for web client updates to multiple tables
> >
> >
> > Commitment control is the "right" answer.
> >
> > I don't see stored procedures solving this without commitment control.
> >
> > Why do you think commitment control is a larger effort to implement?
> >
> > Charles
> >
> >
> > On Tue, Dec 31, 2013 at 12:59 PM, J Franz <franz400@xxxxxxx> wrote:
> >
> > > Having an interesting discussion with our C# developers over best
> method
> > > to insert/update new orders to our system. No current journaling on the
> > 11
> > > tables updated for a new order.
> > > We have had instances of "partial updates" in our testing.
> > > The failed updates could be time-outs, user cancelling session (after
> > long
> > > delay), or logic halt in client (they are working on identifying
> those).
> > > These are customer entered orders, not employee entered, and network
> > > issues can be a factor.
> > > There are couple tables that hold the "working order" until submit.
> > > I have suggested update through stored procedure, so all the final
> > updates
> > > are code running on the i.
> > > Committment control has been mentioned as well, but seen as a much
> larger
> > > effort to implement.
> > > This would be many hundreds of orders per day.
> > > Jim Franz
> > > --.