• 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: Q <email@hidden>
  • Date: Fri, 4 Jul 2008 17:08:58 +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.

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?

Now try and think about the case for three simultaneous violations, network, database or application level disruption and how to deal with contention and retries and your head will start to really hurt.. I know mine does.


In a word, don't try it, ok that's three words. Unless you can do it atomically with either database level uniqueness, or a table level locking you are going to just torture yourself.

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.

There are probably plenty of reasons, they just aren't obvious. What if the detection detects a conflict but the reversal fails?


--
Seeya...Q

Quinton Dolan - email@hidden
Gold Coast, QLD, Australia (GMT+10)
Ph: +61 419 729 806



_______________________________________________
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:
    • [SOLVED] Re: DB uniqueness constraints and dealing with them
      • From: Florijan Stamenkovic <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: ERXLocalizer getting rid of the binding errors?
  • Next by Date: empty relationship qualifier question
  • Previous by thread: Re: DB uniqueness constraints and dealing with them
  • Next by thread: [SOLVED] Re: DB uniqueness constraints and dealing with them
  • Index(es):
    • Date
    • Thread