X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id D79ED3B4EE8 for ; Wed, 15 Dec 2004 21:27:47 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 31779-05 for ; Wed, 15 Dec 2004 21:27:31 +0000 (GMT) Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.250.190.2]) by svr1.postgresql.org (Postfix) with ESMTP id 79E7E3B4F1C for ; Wed, 15 Dec 2004 21:27:31 +0000 (GMT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id A366B3195C; Wed, 15 Dec 2004 22:27:31 +0100 (MET) From: Christopher Browne X-Newsgroups: pgsql.interfaces Subject: Re: Lost updates vs resumable connections/transactions Date: Wed, 15 Dec 2004 16:22:49 -0500 Organization: Afilias Canada - Operations Group Lines: 42 Message-ID: <60ekhrdzo6.fsf@dba2.int.libertyrms.com> References: <41C06961.8020406@Yahoo.com> <87is73qrde.fsf@stark.xeocode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) Cancel-Lock: sha1:vapchy+VrXurABKjt8ErZ/kOjtI= To: pgsql-interfaces@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200412/34 X-Sequence-Number: 5204 gsstark@mit.edu (Greg Stark) writes: > Jan Wieck writes: >> Even applications that have statefull enduser terminals (like SAP R/3 for >> example) never allow an open transaction over user interaction. > > I'm not sure using SAP as your paragon of design excellence is a > wise choice here. From what I understand SAP implemented its own > locking system because the database it was based on didn't offer any > locking at all. I don't think "design excellence" is the point; I'd point at Sabre/STS as another example of "never an open transaction"). You (as a travel agent, out at the "client level") don't get to open up user level transactions to the airline reservation system. Instead, you fill a 3270 screen or some part thereof with data, and then submit an "update." As a result, each request is a fully-formed transaction, if a small one. > But your basic point is sound. For a web site I would definitely > avoid using anything like database locks and even avoid doing > anything with application locks if possible. > If you really really want to expose the database session state I > think he's on the right track using SQLRelay. This would let him > handle reconnecting a user with her session even if she's connecting > to a different Apache process. We've got some web apps where it would be kind of nice to keep a cursor around for a little while. But there have been plenty of times when I have had to rue the fact of transactions being held open for a long time by one thing or another... -- "cbbrowne","@","ca.afilias.info" Christopher Browne (416) 673-4124 (land)