This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Path: nntp.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!panix!news.panix.com!panix3.panix.com!not-for-mail From: kj0 <kj0@mailcity.com> Newsgroups: comp.lang.perl.misc Subject: CGI.pm & transaction management Date: 10 Sep 2000 11:23:59 -0400 Organization: none Lines: 25 Message-ID: <8pg92f$kkl$1@panix3.panix.com> NNTP-Posting-Host: panix3.panix.com X-Trace: news.panix.com 968599439 4837 166.84.0.228 (10 Sep 2000 15:23:59 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: 10 Sep 2000 15:23:59 GMT X-No-Archive: yes X-No-Confirm: yes X-Newsreader: NN version 6.5.6 (NOV) Xref: nntp.stanford.edu comp.lang.perl.misc:341002 The state-less model of cookie-free CGI-based interaction makes it a bit difficult to prevent accidental duplicate transactions. For example, if a user submits a request to perform a financial transaction or to write new data to a database, and sees that his/her browser hangs, s/he has no good way of knowning whether the transaction went through or should be re-submitted. Or, seeing the browser hang, the user may get impatient and hit the Reload button, unaware of the possibility of sending a duplicate submission of the original transaction. One can come up with more scenarios in which the user, while seemingly only navigating the site, may inadvertently cause duplicate transactions to take place. Since this problem is so common, I imagine that already there are several standard solutions to it, maybe including some that can be implemented as part of CGI.pm-based scripts. Where can I read about these solutions? Thank you, KJ Path: nntp.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!news.megsinet.net.MISMATCH!news.corecomm.net!news.xnet.com!efflandt From: efflandt@xnet.com (David Efflandt) Newsgroups: comp.lang.perl.misc Subject: Re: CGI.pm & transaction management Date: Sun, 10 Sep 2000 16:18:42 +0000 (UTC) Organization: XNet Information Systems, Inc. Lines: 31 Message-ID: <slrn8rnd2o.g4e.efflandt@efflandt.xnet.com> References: <8pg92f$kkl$1@panix3.panix.com> Reply-To: efflandt@xnet.com NNTP-Posting-Host: efflandt.xnet.com X-Trace: flood.xnet.com 968602722 16525 199.245.227.117 (10 Sep 2000 16:18:42 GMT) X-Complaints-To: abuse@xnet.com NNTP-Posting-Date: Sun, 10 Sep 2000 16:18:42 +0000 (UTC) User-Agent: slrn/0.9.5.7 (UNIX) Xref: nntp.stanford.edu comp.lang.perl.misc:341007 On 10 Sep 2000 11:23:59 -0400, kj0 <kj0@mailcity.com> wrote: > >The state-less model of cookie-free CGI-based interaction makes it a >bit difficult to prevent accidental duplicate transactions. For >example, if a user submits a request to perform a financial >transaction or to write new data to a database, and sees that his/her >browser hangs, s/he has no good way of knowning whether the >transaction went through or should be re-submitted. Or, seeing the >browser hang, the user may get impatient and hit the Reload button, >unaware of the possibility of sending a duplicate submission of the >original transaction. One can come up with more scenarios in which >the user, while seemingly only navigating the site, may inadvertently >cause duplicate transactions to take place. > >Since this problem is so common, I imagine that already there are >several standard solutions to it, maybe including some that can be >implemented as part of CGI.pm-based scripts. You might get better answers from a more appropiate .cgi newsgroup, since the issue is not Perl specific. Common sense would dictate checking if such a transaction from that person was recently completed (if it matters or requires payment), and asking them to confirm the total (including previous transactions) before accepting it. -- David Efflandt efflandt@xnet.com http://www.de-srv.com/ http://www.autox.chicago.il.us/ http://www.berniesfloral.net/ http://hammer.prohosting.com/~cgi-wiz/ http://cgi-help.virtualave.net/ Path: nntp.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed1.news.rcn.net!rcn!stevel From: stevel@bluetuna.com (Steve Leibel) Newsgroups: comp.lang.perl.misc Subject: Re: CGI.pm & transaction management Date: Sun, 10 Sep 2000 13:33:58 -0700 Lines: 32 Message-ID: <stevel-1009001334260001@192.168.100.2> References: <8pg92f$kkl$1@panix3.panix.com> X-Trace: ewA2pIEXge2d2yEX0UNWdD8eju+SP3s8CPAfE3p6K0U= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 10 Sep 2000 20:34:07 GMT X-Newsreader: MT-NewsWatcher 2.4.4 Xref: nntp.stanford.edu comp.lang.perl.misc:341037 In article <8pg92f$kkl$1@panix3.panix.com>, kj0 <kj0@mailcity.com> wrote: > The state-less model of cookie-free CGI-based interaction makes it a > bit difficult to prevent accidental duplicate transactions. For > example, if a user submits a request to perform a financial > transaction or to write new data to a database, and sees that his/her > browser hangs, s/he has no good way of knowning whether the > transaction went through or should be re-submitted. Or, seeing the > browser hang, the user may get impatient and hit the Reload button, > unaware of the possibility of sending a duplicate submission of the > original transaction. One can come up with more scenarios in which > the user, while seemingly only navigating the site, may inadvertently > cause duplicate transactions to take place. > > Since this problem is so common, I imagine that already there are > several standard solutions to it, maybe including some that can be > implemented as part of CGI.pm-based scripts. > > Where can I read about these solutions? One idea is session id's. When the user first submits the HTML form, the "action" url is www.whatever.com/cgi-bin/myprog for example. This url has no query string. When your CGI sees the absence of a query string, you know it's their first time in. Randomly assign a number (say, 12345), record their state in your database, and send them back a redirect to www.whatever.com/cgi-bin/myprog?12345. Now you know who they are as long as they stay in that browser window and keep talking to your cgi, and you can keep track of their state in your database. Steve L From: brlspam@sperience.com Subject: Re: CGI and Postgres Reply-To: brlspam@sperience.com Organization: MIT Alumni References: <vsitsqon0r.fsf@sundog.larc.nasa.gov> Message-ID: <nm9em3dqxyf.fsf@kindness.mit.edu> Newsgroups: comp.infosystems.www.authoring.cgi Approved: Self-Moderation <authoring-cgi@boutell.com> NNTP-Posting-Host: 206.125.69.81 Date: 25 Aug 2000 15:37:17 -0600 X-Trace: 25 Aug 2000 15:37:17 -0600, 206.125.69.81 Lines: 20 X-Original-NNTP-Posting-Host: 204.157.220.254 Path: nntp.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.primenet.com!nntp.gblx.net!nntp-cust.primenet.com!huge.aa.net!206.125.69.81 Xref: nntp.stanford.edu comp.infosystems.www.authoring.cgi:92101 Robert Kernell <kernell@sundog.larc.nasa.gov> writes: : Hi. IF I allow additions to a database through a web page, do I have to : worry about simultaneous adds and retrieves? Does the Postgres system : take care of that? Postgres takes care of that. It's one of the big reasons for using a relational database. Read an explanation of the ACID test at http://www.arsdigita.com/books/panda/databases-choosing -- Bruce R. Lewis http://brl.sourceforge.net/ -- PLEASE NOTE: comp.infosystems.www.authoring.cgi is a SELF-MODERATED newsgroup. aa.net and boutell.com are NOT the originators of the articles and are NOT responsible for their content. You can SELF-APPROVE your first posting by writing the word 'passme' on a line by itself. From: ellis@ftel.net (Rick Ellis) Subject: Re: CGI and Postgres Reply-To: ellis@ftel.net (Rick Ellis) Organization: Franklin interNet http://www.franklin.net References: <vsitsqon0r.fsf@sundog.larc.nasa.gov> <8o633p$q3f$1@nnrp1.deja.com> Message-ID: <8oorsu$l68$1@ting.ftel.net> Newsgroups: comp.infosystems.www.authoring.cgi Approved: Self-Moderation <authoring-cgi@boutell.com> NNTP-Posting-Host: 204.137.133.236 Date: 1 Sep 2000 16:00:36 -0600 X-Trace: 1 Sep 2000 16:00:36 -0600, 204.137.133.236 Lines: 24 X-Original-NNTP-Posting-Host: 204.157.220.254 Path: nntp.stanford.edu!newsfeed.stanford.edu!nntp.cs.ubc.ca!newsfeed.direct.ca!look.ca!nntp.primenet.com!nntp.gblx.net!nntp-cust.primenet.com!huge.aa.net!204.137.133.236 Xref: nntp.stanford.edu comp.infosystems.www.authoring.cgi:92252 In article <8o633p$q3f$1@nnrp1.deja.com>, Destroyed Lolo <l_faillie@yahoo.com> wrote: :: Hi. IF I allow additions to a database through a web page, do I have to :: worry about simultaneous adds and retrieves? Does the Postgres system :: take care of that? When I read about this in my books it only mentions :: this being a concern in regard to files. Thanks. You can post a reply, :: or by email to: kernell@sundog.larc.nasa.gov :I don't think you need to worry about such thing as Postgres handle :itself concurrent access. While Postgres does handle concurrent access it can't read your mind. It can be quite important to use the transaction facilities to ensure the database remains consistant. -- http://www.fnet.net/~ellis/photo/ -- PLEASE NOTE: comp.infosystems.www.authoring.cgi is a SELF-MODERATED newsgroup. aa.net and boutell.com are NOT the originators of the articles and are NOT responsible for their content. You can SELF-APPROVE your first posting by writing the word 'passme' on a line by itself.