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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
