Re: commit control for an interactive web app, is this feasible

On Tue, 7 Aug 2001 15:15:11 -0400
 jon.paris@e400.com wrote:
> 
>  >> Commitment Control really shouldn't require
> persistence.
> 
> How can this be Brad?  Unless you assume that all updates
> occur within one
> message pair.  

You removed the part of my message that said it was.
Persistence can be handled in more than one way.  And true
persistent CGI is the most cumbersome of them all.  Not to
mention a waste of jobs.

Are you assuming a site will do page after page of updates?
I am not.  Maybe that's where the difference is in our
thinking.

In my scenario a piece of info is passed along, like in a
shopping basket ID.  Then, when all is said and done the
user clicks "checkout" and all the updates happen, all in
one job, all in one AG.  I wouldn't want to do little
updates all the way through the process.  And I wouldn't use
CC on a shopping basket type file.  That would be
unnecessary.

> You can't even guarantee that you'll be
> connecting to the
> same server job and therefore cannot guarantee the same
> AG.  Since the AG
> is where the commitment control is "tied" how can it
> work? 

See above.  I think we're on different pages regarding the
CGI apps in our head.  What did you have in mind as far an
an app that would require CC and multiple steps along in the
job?

 I'd love you to
> prove me wrong, I just don't see how the system would
> handle the mechanics
> of it.   If Net.Data does it maybe it's somehow using a
> separate job to
> handle the actual data access - or else it is using some
> form of
> persistence under the hood.

No, Net.Data is just fancy CGI.  In fact, you have to tell
it to NOT use CC or it will and updates will fail without
it.

Brad