Re: editing context locking
Re: editing context locking
- Subject: Re: editing context locking
- From: Chuck Hill <email@hidden>
- Date: Wed, 6 Apr 2005 14:40:20 -0700
On Apr 6, 2005, at 2:15 PM, Florijan Stamenkovic wrote:
Yes, I did go through Practical WO on locking, and know about the
defaultEC, and having multithreading debugging on. And know that is
regarded as the best practice, and am using exactly what you described
(create and lock in constructor, unlock in sleep, lock in awake).
I was just wondering was it in this case necessary... Because it is
impossible for any other concurrent user to try to fetch, insert,
update or whatever on those objects, as they are still not
"officially" there. And that is what locking is supposed to prevent in
the first place, right???
So, I see that it is best practice and a "law to obey", but is it in
the situation of creating new objects in a new editing context
necessary?
Yes, it is always necessary.
Oh... And for disposing the ec i use:
public void sleep()
{
ec.unlock();
System.out.println("ADDDRAWING component sleep() called - ec
unlocked");
if(! ec.hasChanges()) //in my construction in can not be without
changes unless it was just saved to the parent ec
{
System.out.println("ADDDRAWING component sleep() called - will
dispose ec");
ec.dispose();
ec = null;
just to be safe.
System.out.println("ADDDRAWING component sleep() called - did
dispose ec");
}
super.sleep();
}
Logging told me that all the right actions are happening in the right
time. Is this really the way to do it???
yes.
Chuck
On Apr 06, 2005, at 21:06, Kaj Hejer wrote:
On 6. apr 2005, at 20.45, Florijan Stamenkovic wrote:
When I am creating new objects within a completely new editing
context (nested into the default one) do I _need_ to lock???
Yes! You should always lock any ec you create yourself. The only ec
you don't need to lock is session.defaultEditingContext.
The best thing is to lock the ec just after it is created. You can
unlock f.x. in sleep in the component (or some other place :)
You might want to take a look at MultiECLockManager, see
<http://www.wocode.com/WOCode/Files/MultiECLockManager.java>
To dedect access to any ec that is not lock (as it should be! :) add
the following lines to the constructor in your Application.java:
NSLog.debug.setAllowedDebugLevel(NSLog.DebugLevelInformational);
NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupMultithreading);
setAllowsConcurrentRequestHandling(true);
You find a good guide to the art of locking editingcontexts in the
book "Practical WebObjects", see
<http://www.global-village.net/products/practical_webobjects>.
-Kaj :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development 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