|
Regarding persistence, I believe that persistence has a number of valuable benefits: Activation group is already established (not re-established) after the first call. Data paths are reused (not re-opened) on successive calls. Custom environment variables can be used. 1st time run procedures, do just that run the 1st time only....... (this should sound familiar for all you green-screen guys) If you have an application that accesses data to any degree this is the way to go....... I am using commitment control under this type of environment without any difficulty. Andrew "Brad Stone" <brad@bvstools. To: WEB400@midrange.com com> cc: Sent by: Subject: [WEB400] Re: commit control for an interactive web app, is web400-admin@mi this feasible drange.com 08/07/2001 11:19 PM Please respond to web400 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 _______________________________________________ WEB400 mailing list WEB400@midrange.com http://lists.midrange.com/cgi-bin/listinfo/web400
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.