Re: [SOLVED] Re: DB uniqueness constraints and dealing with them
Re: [SOLVED] Re: DB uniqueness constraints and dealing with them
- Subject: Re: [SOLVED] Re: DB uniqueness constraints and dealing with them
- From: Florijan Stamenkovic <email@hidden>
- Date: Fri, 04 Jul 2008 11:11:55 -0400
One more question though... An adapter exception *is* thrown,
regardless of the database backing EOF, right? No standardized info
is provided, but it is guaranteed that the exception is thrown, right???
F
On Jul 04, 2008, at 11:03, Florijan Stamenkovic wrote:
Right all, well, thanks everyone for sinking that ship of an idea
down to the abyss, where it apparently belongs :)
Arghhh... So, the seems to be no way to really properly handle
this, is there?
Paul, thanks for the code, I am currently deploying on OpenBase, I
will look into what kind of info the adapter exception gives me
there... Perhaps your code will help.
Again, many thanks everyone from saving me from attempting this.
F
On Jul 04, 2008, at 03:08, Q wrote:
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:
40mac.com
This email sent to email@hidden
_______________________________________________
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