X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id F2BE0538A8 for ; Wed, 4 May 2005 08:40:44 -0300 (ADT) 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 37246-01 for ; Wed, 4 May 2005 11:40:36 +0000 (GMT) Received: from mail.logix-tt.com (wallaby.dingens.org [212.75.36.180]) by svr1.postgresql.org (Postfix) with ESMTP id C515B53873 for ; Wed, 4 May 2005 08:40:34 -0300 (ADT) Received: from kingfisher.intern.logi-track.com (pD95DD6C8.dip0.t-ipconnect.de [217.93.214.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id 15FCFA86C4; Wed, 4 May 2005 13:40:36 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logi-track.com (Postfix) with ESMTP id 29485AB0DC; Wed, 4 May 2005 13:38:31 +0200 (CEST) Message-ID: <4278B436.6050102@logix-tt.com> Date: Wed, 04 May 2005 13:38:30 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-sql Cc: weigelt@metux.de Subject: Re: Mutex via database References: <20050504112846.GA8968@nibiru.borg.metux.de> In-Reply-To: <20050504112846.GA8968@nibiru.borg.metux.de> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200505/36 X-Sequence-Number: 21349 Hi, Enrico, Enrico Weigelt wrote: > i've a dozen of servers processing jobs from a database. > Some servers may only run exactly once, otherwise I'll get jobs > done twice. > > Is there any way for implementing an kind of mutex within the > database, which is automatically released if the holding > process/connection dies ? Use the "LOCK" sql command, possibly together with transaction isolation set to serializable. Markus