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

I think it depends on how you've implemented commitment control in the past.
I, for one, consider it a cardinal sin to have a commitment boundary open
across screens. I would never:

BEGIN CC
SHOW SCREEN 1
PROCESS SCREEN 1
SHOW SCREEN 2
PROCESS SCREEN 2
COMMIT

I would always structure my code so that I was:

BEGIN CC
SHOW SCREEN 1
PROCESS SCREEN 1
COMMIT <=== NB
SHOW SCREEN 2
PROCESS SCREEN 2
COMMIT

No one has ever been able to show me a good reason to hold commitment
boundaries across screens. Assuming my premise, you would never need
persistence to use CC in a web environment either.

-Walden

-----Original Message-----
From: jon.paris@e400.com [mailto:jon.paris@e400.com]
Sent: Tuesday, August 07, 2001 3:15 PM
To: WEB400@midrange.com
Subject: Re: commit control for an interactive web app, is this feasible



 >> Commitment Control really shouldn't require persistence.

How can this be Brad?  Unless you assume that all updates occur within one
message pair.  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?  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.



+---
| This is the WEB400 Mailing List!
| To submit a new message, send your mail to WEB400@midrange.com.
| To subscribe to this list send email to WEB400-SUB@midrange.com.
| To unsubscribe from this list send email to WEB400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the WEB400 Mailing List!
| To submit a new message, send your mail to WEB400@midrange.com.
| To subscribe to this list send email to WEB400-SUB@midrange.com.
| To unsubscribe from this list send email to WEB400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---