Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 8590 invoked from network); 22 Nov 2005 13:37:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Nov 2005 13:37:38 -0000 Received: (qmail 49115 invoked by uid 500); 22 Nov 2005 13:37:32 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 49047 invoked by uid 500); 22 Nov 2005 13:37:32 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 49032 invoked by uid 99); 22 Nov 2005 13:37:32 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2005 05:37:32 -0800 Received-SPF: pass (asf.osuosl.org: domain of jak-commons-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2005 05:39:04 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EeYHL-0004oX-DB for commons-dev@jakarta.apache.org; Tue, 22 Nov 2005 14:33:47 +0100 Received: from srvgw12.rauser-ag.com ([217.146.133.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Nov 2005 14:33:47 +0100 Received: from joerg.heinicke by srvgw12.rauser-ag.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Nov 2005 14:33:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: commons-dev@jakarta.apache.org From: Joerg Heinicke Subject: Re: [transaction] Duplicated TxId generation under heavy load Date: Tue, 22 Nov 2005 13:31:19 +0000 (UTC) Lines: 26 Message-ID: References: <43830EE2.3080505@is-micro.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 217.146.133.165 (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7) Sender: news X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Cservenak Tamas is-micro.hu> writes: > The generatedUniqueTxId() method in FileResourceManager uses > System.currentTimeMillis() to generate txId's. > > On my system it causes duplicate txId generation and FRM failure. I have > 4 threads accessing one FRM instance. > > This simple patch adds "salt" to it, with a little overhead to solve > this problem. Unfortunately this does not help much, it only solves your problem "under heavy load". But if there is already another txId equal to this one (e.g. generated externally) FRM will again fail. It can only work if inside the synchronized block the generated txId is "preserved", e.g. by putting a final static object PRESERVED into the map and testing for it in the startTransaction(Object) method. This will solve almost all problems except one: 1. Thread 1: generateUniqueTxId() 2. Thread 2: startTransaction(txId) with an externally generated txId - coincidentally equal to the above generated one 3. Thread 1: startTransaction(txId) with the generated txId But is again a magnitude more unlikely. Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org