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


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].