• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: DB uniqueness constraints and dealing with them
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DB uniqueness constraints and dealing with them


  • Subject: Re: DB uniqueness constraints and dealing with them
  • From: Lachlan Deck <email@hidden>
  • Date: Fri, 4 Jul 2008 14:47:04 +1000

On 04/07/2008, at 1:01 PM, Florijan Stamenkovic wrote:

The save -> error check is exactly what I had in mind, sorry if I was not clear about it. However, I would rather like to delete the newly saved EO, and throw a validation exception. But this is only possible if I can find the exactly same EO, once before it saved to the db, and once after. Is that possible? Huh, never thought about this.

You'll need the pk to fetch on. Do you need to set a flag that says 'pendingUniquenessCheck' so that it's only available to be read from other contexts when pending is false.... yada yada.


To answer Q's question, yes, it is a race condition, but a rather funky one. Because each thread, regardless in which app instance or even which machine they are one, checks for the record uniqueness after it has saved it. So, it can happen that there are two records saved that violate the uniqueness, but it will be detected. And the EO created in the thread that detected the uniqueness violation should be deleted. As far as I can see, this can never result in having the uniqueness violated. In some circumstances however it could result in all attempts failing. That would be the race condition in this setup... If both processes manage to save at first, then the first process detects the violation, but the second process kicks in before the first deletes it's EO, then the second one will also detect a violation. Both fail. See what I mean?

But perhaps I do not see it clearly, and somehow uniqueness could be violated? I've been trying to run multithreaded (non synchronized) scenarios in my head, and I can never come to one in which the uniqueness is violated and not detected.

This is really something that can lead to chasing one's tail in the absence of database-level unique constraints.


e.g.,
- what happens if your application dies whilst checking whether or not the uniqueness is violated post save?
- what happens if you have multiple instances running and before the uniqueness is fixed another instance tries to EOUtilities.objectFor... they'll get an exception.


with regards,
--

Lachlan Deck



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: DB uniqueness constraints and dealing with them
      • From: Chuck Hill <email@hidden>
References: 
 >DB uniqueness constraints and dealing with them (From: Florijan Stamenkovic <email@hidden>)
 >Re: DB uniqueness constraints and dealing with them (From: Q <email@hidden>)
 >Re: DB uniqueness constraints and dealing with them (From: Jerome Chan <email@hidden>)
 >Re: DB uniqueness constraints and dealing with them (From: Florijan Stamenkovic <email@hidden>)

  • Prev by Date: Re: Back To Basics : Databases Active Editing Context
  • Next by Date: Re: DB uniqueness constraints and dealing with them
  • Previous by thread: Re: DB uniqueness constraints and dealing with them
  • Next by thread: Re: DB uniqueness constraints and dealing with them
  • Index(es):
    • Date
    • Thread