Re: Best way to generate unique IDs that are not PKs
Re: Best way to generate unique IDs that are not PKs
- Subject: Re: Best way to generate unique IDs that are not PKs
- From: Sacha Michel Mallais <email@hidden>
- Date: Tue, 2 Jan 2007 11:30:55 -0800
On Dec 31, 2006, at 7:11 AM, Florijan Stamenkovic wrote:
I have a need in several of my tables to generate identifying
numbers, but relative to a certain relationship. So, if there is a
Book, I need to generate number 6 for it if Author currently
relates to 5 other books... I have an approach of doing this,
please anyone tell me if there is a better way to do it!
IMHO, the better way would be to get rid of the requirement
altogether and use normal PK generation.
My approach:
1. Lock the working thread on a monitor that is "static final" in
my SessionWorker class
2. Get the next number by using aBook.valueForKeyPath
("email@hiddeneNumber"); //can not use @count in case of
previous deletions
3. Set the next number in aBook
4. Save the changes of my working editing context
5. Release the synchronization lock
This appears sound, though as you note below, this will work only if
you have a single instance.
Questions:
Is there way to use EOF locking to lock on the database? It seems
to me that would be more appropriate for what I am doing then the
plain Java thread synching, and would work even if there were
multiple application servers running, where the above approach
would not. Any other ideas where this might flop and how to prevent
it?
I think you're going to need to lock the entire table from any access
during your transaction in order to guarantee no race condition (a
read lock will not be sufficient). You can try the
EOFetchSpecification.locksObjects() method, but I don't think that
will do it: I think that does a SELECT FOR UPDATE, which obtains a
read lock. That means that you'll need to go behind EOF's back and
send the database-specific command yourself to lock down any access
to that table for the length of the transaction. This, of course,
has performance implications.
Shaun suggested using a stored procedure, which, if you're using a
database that has them, is a good idea -- as is a unique constraint
on those columns.
sacha
_______________________________________________
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