I was thinking of a different approach to doing it "off to the side", such
as using a separate (buffer) table where the processing is done, then
moving it in to your primary table at the end. This provides for a bit
more auditting than the hidden fields do, but is more expensive. If you
don't care about auditting the user session, then I'd say (IMHO) that
hidden fields is probably the best, safest way to go.
____________________________
Jeff Seger
Fairchild Semiconductor
[EMAIL PROTECTED]
____________________________
Wieland Pusch <[EMAIL PROTECTED]>
03/10/2004 08:18 AM
Please respond to Wieland Pusch
To: [EMAIL PROTECTED]
cc:
Subject: Re: Span a database transaction across multiple CGI scripts
Hello,
Sagara Wijetunga <[EMAIL PROTECTED]> wrote:
>>
>> Is it possible to span a database transaction across
>> multiple CGI scripts? That is, start transaction and
>> lock some records in one CGI script and update and
>> commit in another CGI script.
RJK> One possible approach is to set up a separate process that runs in
the
RJK> background, perhaps as a daemon, and handles all the actual database
RJK> requests. You would use some sort of session identifier in your CGI
RJK> scripts, passing it to the background process so it could manage the
RJK> requests appropriately. Each session would get its own connection to
the
RJK> database so that the transaction locking would be effective.
AFAIK
It is possible if the CGI script is run by a process that is never
ending. You can do that with Apache/mod_perl.
But be careful HTTP is stateless. You never know that the user will
not close the brower instead of clicking "next".
The better way is to collect the infos e.g. in hidden input fields and
access the database only with the last page.
But you want locking. So you need some kind of timeout for your
transaction.
How about not using database locking but user implemented locking?
HTH
Wieland mailto:[EMAIL PROTECTED]
