Re: To lock() or not to lock()
Re: To lock() or not to lock()
- Subject: Re: To lock() or not to lock()
- From: Art Isbell <email@hidden>
- Date: Mon, 9 Oct 2006 14:28:25 -1000
On Oct 9, 2006, at 12:39 PM, Ricardo Parada wrote:
I have an EOF question regarding locking. The documentation on the
EOEditingContext lock() method says the following:
I have found the Concurrency and Locking discussion at <http://
developer.apple.com/documentation/WebObjects/WhatsNew5.2/WhatsNew/
chapter_1_section_7.html#//apple_ref/doc/uid/TP40000966-1-TPXREF65>
to be much more comprehensive.
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? Or should I lock the
editing contexts?
I periodically reread the attached message because it enforces the
need to lock all editing contexts that aren't the session's default
editing context. Ben Trumbull knows more about the low-level
operation of EOF than most of us, so his advice should be considered
carefully.
On Jul 22, 2003, at 4:04 PM, Ben Trumbull wrote:
The documentation is explicit about the need to lock your editing
contexts. We all want things to get better and easier. Certainly
this area of locking leaves a lot to be desired.
You should be able to lock and unlock in awake() and sleep() in
either your session class or your component class. Any failures
for this to work as you expect should be reported to <http://
bugreport.apple.com>
Apparently, there are situations in which WOComponent's sleep() is
not invoked after an awake() invocation which would leave an editing
context locked in awake() locked. Jonathan Rochkind's
MultiECLockManager works around this problem.
There is an unfortunate statement which some people have
misconstrued. Hopefully most people will conclude that when an
absolute statement and an ambiguous statement collide, the effect
is quite similar to a train v.s. motorcycle accident.
As Chuck points out, there is a world of difference between "the
parent's lock being locked once" and "invoking the lock method".
Failure to invoke the lock method is BAD. Invoking the lock and
unlock methods are crucial signals to EOF about which resources
(i.e. ECs) are in use and which are not.
Concurrent request handling only affects the WebObjects Framework
classes (WOApplication, session, component, direct action, request
handlers ...). This makes things much simpler for people writing
sessions and components. EOF is an entirely different layer of
frameworks.
There is no way to turn off multithreaded access to
EOEditingContexts. None. Think of lock & unlock as being
reserveResourceForUse & doneWithResourceUse.
You cannot stop the garbage collection of unreferenced EOs by
locking the EC. The only way to stop GC of EOs is to hold a strong
reference to them yourself, or setRetainsRegisteredObjects() for
that EC.
The essence here is that GC uses the EOF stack. Since details are
subject to change without notice, I won't provide any.
Aloha,
Art
_______________________________________________
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