Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 51847 invoked from network); 15 Sep 2006 15:43:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Sep 2006 15:43:32 -0000 Received: (qmail 24897 invoked by uid 500); 15 Sep 2006 15:43:28 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 24883 invoked by uid 500); 15 Sep 2006 15:43:28 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 24872 invoked by uid 99); 15 Sep 2006 15:43:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Sep 2006 08:43:28 -0700 X-ASF-Spam-Status: No, hits=1.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [206.190.36.82] (HELO smtp104.rog.mail.re2.yahoo.com) (206.190.36.82) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 15 Sep 2006 08:43:17 -0700 Received: (qmail 61699 invoked from network); 15 Sep 2006 15:41:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=Zu7CaEUehsnxehLkY1q4IIcuo08lEEadJcFUWslqTDGfv86GW9V+GKhJK5uucRej/BbrU72oQiWKgmsiaN0EP6GBtxr9UKckOccI8Q4LKfjz+M5OvJv96R4Hfe5MBMHkYrUN6bvqk4dBfBdd/D2RPfu4UtEQPRX+LbzWtLHSbTA= ; Received: from unknown (HELO RIGCISERVER) (serjann@rogers.com@72.61.44.214 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 15 Sep 2006 15:41:31 -0000 Message-ID: <1ad601c6d8dd$233c8a60$0601a8c0@RIGCISERVER> From: "Edwin Lukaweski" To: References: <1a9701c6d8d0$ab1030c0$0601a8c0@RIGCISERVER> <1aa601c6d8d5$dab841a0$0601a8c0@RIGCISERVER> Subject: Re: finding unique keys Date: Fri, 15 Sep 2006 11:39:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Thanks for all the feed back!!! Some answers: 1) I am using DB2 for z/OS version 7 2) Yes, UUID's are by definition 'universally unique', excpept whe two are gengerated, say by two different JVMs, within the same millisecond. The, they turn out to be duplicates. 3) I like the idea of doing an optimistic INSERT. I have always had trouble figuring which sql code to look for that represents this situation. As best I can tell, it is SQLCODE 803. So, if I see this code in an exception, loop again, otherwise throw a real sqlexception. What do you think? thanks, Edwin ----- Original Message ----- From: "Larry Meadors" To: Sent: Friday, September 15, 2006 11:03 AM Subject: Re: finding unique keys > +1 ;-) > > Larry > > > On 9/15/06, Jeff Butler wrote: >> >> Some thoughts... >> >> 1. Aren't UUID's "universally unique" by definition? Are you sure you >> need >> to do this? >> >> 2. Table locking is almost always a bad idea. I had a similar situation >> to >> yours in that past, and decided to take the optomistic route, meaning... >> >> - generate the key >> - insert the record >> - if the insert blows because of a duplicate key, then generate a new key >> and try again >> >> Since the likelihood of generating a duplicate UUID should be very low, >> this >> approcah will work in the vast majority of cases. >> >> >> Jeff Butler >> >> >> >> >> On 9/15/06, Edwin Lukaweski wrote: >> > Thanks for the answer. >> > >> > I am stuck with an existing table definition, in a schema, that I >> cannot >> > modify at this point due to being in production. >> > >> > So, this is the best method I can come up with. >> > >> > also....now you have tweaked my curiosity. In addition to the advice >> > I >> > am seeking, it I could alter the table definition to use some form of >> > auto-increment, how would I retrieve the generated value in iBatis? >> > >> > So.....I now have two questions. >> > >> > thanks, >> > Ediwn >> > >> > ----- Original Message ----- >> > From: "Larry Meadors" < lmeadors@apache.org> >> > To: >> > Sent: Friday, September 15, 2006 10:14 AM >> > Subject: Re: finding unique keys >> > >> > >> > > One question: Why not just let the database do it and have it tell >> > > you >> > > the generated key? >> > > >> > > Larry >> > > >> > > >> > > On 9/15/06, Edwin Lukaweski wrote: >> > >> >> > >> >> > >> Hi: >> > >> >> > >> I have a situation for which I need some advice while using >> > >> iBatis. >> > >> >> > >> What I would like to do is: >> > >> >> > >> 1) generate a unique UUID style value in my Java program >> > >> >> > >> 2) lock a table, say tabxx >> > >> >> > >> 3) SELECT on the table to see if the UUID exists as a key >> > >> >> > >> 4) if so, add 1 to the key and go to step 3 >> > >> >> > >> 5) if the key does NOT exist, insert the record >> > >> >> > >> 6) unlock the table >> > >> >> > >> Can anyone get me advice as to how to do this with iBatis? >> > >> >> > >> Thanks, very musch, in advance >> > >> >> > >> Edwin >> > >> >> > > >> > >> > >> > >> >> >