Re: To lock() or not to lock()
Re: To lock() or not to lock()
- Subject: Re: To lock() or not to lock()
- From: Chuck Hill <email@hidden>
- Date: Mon, 9 Oct 2006 22:07:18 -0700
On Oct 9, 2006, at 3:39 PM, Ricardo Parada wrote:
Hi All,
I have an EOF question regarding locking. The documentation on the
EOEditingContext lock() method says the following:
---
Locks access to this EOEditingContext to prevent other threads from
accessing it. If it has a shared editing context, this
EOEditingContext takes a reader lock on it as well. You should lock
an editing context when you are accessing or modifying objects
managed by the editing context. The thread safety provided by
Enterprise Objects Framework allows you to have one thread to be
active in each EOEditingContext and one thread to be active in each
EODatabaseContext (EOAccess). In other words, multiple threads can
access and modify objects concurrently in different editing
contexts, but only one thread can access the database at a time (to
save, fetch, or fault).
---
My interpretation of this is that I can have thread1 working in one
editing context and thread2 working in a second editing context.
These two editing contexts by default share the eoaccess level
objects to access the database. So when either thread calls the
EOEditingContext saveChanges() or objectsWithFetchSpecification()
to fetch objects then EOF obtains a lock to prevent the other
thread from accessing the eoaccess layer and doing a save/fetch at
the same time.
So it would seem to me that thread1 and thread2 do not need to
worry about locking their editing context when they are using
them. I would have to worry about locking an editing context only
if I were to have separate threads working on the same editing
context. Are these assumptions valid?
No, not at all. Fetches, saves, etc send notifications to the
editing contexts in other threads.
Or should I lock the editing contexts?
As Art indicated - yes!
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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