>>>> >>>> Barring that I was thinking maybe check both before and after the >>>> save. If there did happen to be two after the save, I could add a >>>> number after the filed to make it unique and save it again, of >>>> course notifying the user of the new name. Of course I'd have to >>>> check this new name again on the save in the same way as before >>>> until I got one that stuck. >>> >>> Think really carefully about that and about the same thing >>> happening at the same time in two instances. >>> >> Perhaps you could append a random number to the name. > >That just reduces the window for the race condition. You can do it >right, or you can have an approximation of uniqueness. Your app, your >call.
No, this was just for the sake of discussion. multi-column unique index (name + foreignKey ID) is the way to go, now I just have to figure out how to set it up. Thanks! Jeff > > >Chuck > > > >>>> Are there other approaches to this problem? >>> >>> The only reasonable approach is to use a unique index. >>> >>> >>> Chuck >>> >>> >>>> On Jan 21, 2008, at 1:21 PM, Andrew Lindesay wrote: >>>> >>>>> Hello Neil; >>>>> >>>>> What I tend to do is to have a lock in the database and then the >>>>> thread adding the new code has to acquire the lock and write the >>>>> record before being able to unlock the the lock. Addition of a >>>>> unique index will also ensure that the column values are not >>>>> duplicated. >>>>> >>>>> cheers. >>>>> >>>>>> I think that your second idea of checking for the value before >>>>>> insert is prone to a 0.00001% chance of another instance >>>>>> inserting the same random number in between you checking the DB >>>>>> and inserting into the DB. I don't think that WO supports SQL >>>>>> transaction-based mode of operation (although am happy to be >>>>>> educated on this point if it does). I'm not even sure if RawRow >>>>>> based operations can be coerced into using transactions? Using >>>>>> your first idea though, means that I don't need to go down this >>>>>> route. I'd still be interested, in general, in how to avoid >>>>>> these 'millisecond' windows of potential disaster between a read >>>>>> and a write request. >>>>> >>>>> ___ >>>>> Andrew Lindesay >>>>> technology : www.lindesay.co.nz >>>>> business : www.silvereye.co.nz >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/jeffandmonica%40mac.com >>>>> >>>>> This email sent to [email protected] >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>> >>>> This email sent to [email protected] >>>> >>> >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> >>> Practical WebObjects - for developers who want to increase their >>> overall knowledge of WebObjects or who are trying to solve specific >>> problems. >>> http://www.global-village.net/products/practical_webobjects >>> >>> >>> >>> >>> >>> >> >> > >-- >Chuck Hill Senior Consultant / VP Development > >Practical WebObjects - for developers who want to increase their >overall knowledge of WebObjects or who are trying to solve specific >problems. >http://www.global-village.net/products/practical_webobjects > > > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
