Re: Back To Basics : Databases Active Editing Context
Re: Back To Basics : Databases Active Editing Context
- Subject: Re: Back To Basics : Databases Active Editing Context
- From: Chuck Hill <email@hidden>
- Date: Thu, 3 Jul 2008 21:54:40 -0700
On Jul 3, 2008, at 9:30 PM, Lachlan Deck wrote:
On 04/07/2008, at 2:05 PM, Chuck Hill wrote:
On Jul 3, 2008, at 8:00 PM, Lachlan Deck wrote:
On 04/07/2008, at 9:53 AM, Chuck Hill wrote:
If not what does lock() on the EC actually lock ?
It prevents changes in other ECs from affecting what is
happening in the locked EC. The changes are queued and
processed when the EC is unlocked.
If so, shouldn't rest of EC (waiting to save changes) just hang
around and wait instead of trying to access DBcontext and throw
exception? In other words, the exception we are seeing implies
that rest of ECs have no idea there is ec out there locked the
DBcontext.
No, that is just a badly worded exception. What it really means is
Called objectForGlobalID() on the databaseContext's active
editingContext,
edu.uow.ris.framework.LockErrorScreamerEditingContext@1efaa51,
and got back null. The object
: Researcher:(Active_Name=Peter Newnam {rowID=28082;}, is in
editing context
edu.uow.ris.framework.LockErrorScreamerEditingContext@10c6406.
I've seen this happen when attempting to localize an object into
another ec fails... and you find out when attempting to save
changes.
e.g., using some context that wasn't properly locked.
I don't think I recall having seen this. How would that happen?
localInstance using faulting so I can see it resulting in a dummy
fault EO possibly, but not an object in a different EC. Do you
have any more details on this?
Perhaps a parent ec? Is there any child ecs involved here?
I don't recall terribly clearly now as it's been a while... but I
remember that for some strange reason an object that I had in the
shared editing context didn't localize into the ec that I wanted
when attempting to set the relationship - but there was no exception
until saveChanges. It might have been when said ec didn't have its
sharedEc == null, or invalid locking or something.
I recall, when trying to track it down, mucking around with
temporarily unlocking shared ec locks and stuff. But I think it
turned out to be ensuring that the ec in question didn't properly
set its shared ec to null (I think).
Sorry I don't recall much more than that.
Ah, there you go on about the shared EC again. :-P
I had not considered the SEC being involved. That puts a new twist on
things.
Owen, are you using the SEC?
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