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 PROTECTED]"); //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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
