Re: Nested Editing Contexts
Re: Nested Editing Contexts
- Subject: Re: Nested Editing Contexts
- From: Chuck Hill <email@hidden>
- Date: Tue, 10 Apr 2007 08:43:01 -0700
On Apr 6, 2007, at 11:18 PM, Robert Walker wrote:
Here is an excerpt from the Enterprise Objects guild on
concurrency. Notice the fourth bullet point. I don't quite grasp
the meaning of this but maybe that had something to do with your
locking issues on your child EC. Can someone elaborate on the
actual meaning of "Child editing contexts use their parent's
lock." Does this mean that you lock the parent EC and not the
child EC? Or do you still need to lock and unlock child (nested)
ECs? Sometimes I really with the documentation writers would give
more details than a simple blurb that can be taken entirely the
wrong way. I guess asking for a bit of sample code along with the
blurb is just asking too much.
Yeah, I know the right answer and I still find that text confusing.
Here is the short and sweet of it:
1. You are responsible for locking the child editing context
2. When a child EC is locked, it locks it's parent.
I think that #2 is what they meant by "Child (nested) editing
contexts use their parent’s lock."
Chuck
----------------------------------------------------------
Here are a few additional guidelines regarding locking in
Enterprise Objects applications:
In general, you should first secure the appropriate locks on
EOObjectStoreCoordinators before posting notifications that other
Enterprise Objects register to receive.
Enterprise Object delegates do not need to worry about locking
unless they attempt to access additional resources.
Enterprise Objects uses more sophisticated locking objects than
those built in to Java. These objects provide both you and
Enterprise Objects with more control over the scope of critical
regions within applications. This reduces contention and the
possible scenarios that can generate deadlocks.
Child (nested) editing contexts use their parent’s lock.
EOSharedEditingContext objects have a multireader, single-writer lock.
Each EOObjectStore instance and each EOObjectStoreCoordinator
instance may have its own lock.
There is a global lock for loading EOModel files.
On Apr 7, 2007, at 12:51 AM, Kevin Windham wrote:
Since I was under some time constraints with this section of my
program, I ended up using a temporary object and copying the
properties to the actual object if the user saves. I could not
figure out what I was doing wrong with the nested context. I also
could not get it to work at all if I used lock() on it.
I would like to revisit this though when I have some time, so if
anyone has some sample code or knows where I can find an example
of a nested context in actual use, I would appreciate the pointer.
Thanks,
Kevin
On Apr 6, 2007, at 5:51 PM, Ken Anderson wrote:
Kevin,
It would be much more helpful if you could post the exception.
Ken
On Apr 6, 2007, at 6:23 PM, Kevin Windham wrote:
I attempted to implement a nested editing context and ran into a
problem. I would suspect I am violating a rule of some kind, but
I don't know what it would be. My first attempt failed. My
editing page would not load and it would eventually time out and
give "no instance available". I removed the lock and unlock
calls and everything started working as I wanted. Changes and
reverts seems successful from the child context to the parent
context. The problem now is that when I try to saveChanges() on
the defaultContext, I get an exception and the changes cannot be
saved to the DB.
Does this sound familiar to anyone, and can you point me in the
right direction.
Thanks,
Kevin
On Apr 6, 2007, at 9:45 AM, Ken Anderson wrote:
Kevin,
I'm having a little difficulty with your nomenclature and
prepositions :) , but in general, what you're saying is
correct. Just remember, when you perform a saveChanges() on
the child EC, the changes will only be committed to the parent
EC. To get your changes to the DB, that EC has to have
saveChanges() called also.
Ken
On Apr 5, 2007, at 4:42 PM, Kevin Windham wrote:
I am trying to work out how to use a nested editing context in
my app.
I have an object that has a relationship to another object
that it owns. I am currently directing the user to another
page to edit the owned object, and need to implement a nested
context to make save and cancel work properly.
My understanding of how this should work is extremely basic at
this point. Here is what I think I need to do when the user
decides to edit the owned object:
create a new editing context with the default context as its
parent
lock the new ec
Add my owned object into the new child context
set my child page's object variable to the owned object which
is in the child ec
return the child's page to the user
the user now either saves or cancels
call saveChanges or revertChanges based on the user's action
unlock the child ec
dispose the child ec
return the parent page
Am I going wrong here right off the bat, or is this basically
correct.
Thanks,
Kevin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Robert Walker
email@hidden
"There are 10 types of people in the world, those who think in
binary, and those who don't."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
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