MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » December 2013

Re: best practice for web client updates to multiple tables



fixed

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
--.





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact