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: Owen McKerrow <email@hidden>
- Date: Fri, 4 Jul 2008 09:36:11 +1000
Hi Chuck,
Thanks for the quick response and all your answers matched up with my
understanding, which is both a good and a bad thing. ( As in Im glad
I know this stuff but it sucks I still have the problem ).
See below for more....
Owen McKerrow
WebMaster, emlab
Ph : +61 02 4221 5517
http://emlab.uow.edu.au
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
People who prefer typing to pointing then seem to prefer acronyms to
save typing :-)
-Denis Stanton, On people using Command Line Interfaces
On 04/07/2008, at 9:23 AM, Chuck Hill wrote:
On Jul 3, 2008, at 4:05 PM, Owen McKerrow wrote:
So Im going back to basics, just in case I missed something or my
understanding of these things is flawed :
1) What exactly is the Databases active editing context ?
The editing context that is executing saveChanges() and has the
database (EODatabaseContext) locked
Does the EC lock the EODatabaseContext when you call lock() on the
EC ? If not what does lock() on the EC actually lock ?
2) How/When does a EC become the databases active editing context ?
Someplace inside of saveChanges() after / when it locks the DBContext
3) How/When is it no longer considered the databases active
editing context ?
When the save finished (with or without error) and the EC unlocks
the DBContext
4) Should it be possible for an EC to be the active one across
multiple RR Loops ? And if so why ?
No.
Dam cause this the behavior we are defiantly seeing. We are now
logging out the creation of all EC's with the application. So for
example the EC that was considered the active EC in the error I sent
through was created 6 minutes before it caused the error and had
successfully saved etc etc in between times. And when you thrown in
the fact that this will only occasionally happen and only when there
is more than 1 person on the site at a time, it becomes more
confusing still ( and a pain in the butt to produce and track down
the cause ).
5) Is there only one databases active editing context for each
instance of the application or is it one per session ?
There will be zero or one per EOF stack. Usually there is one EOF
stack per instance.
Yup thats what I thought. So any other EC's that call save changes at
this time will sit in a que I assume and be executed when the lock is
released ?
Pierre Frisch and I were looking at this during WWDC. We came to
the conclusion that the error you are seeing is not possible :-)
Yeah I sat down with Daryl Lee at one of the hands on labs and he
also said something similar.
except when you form relationships across editing contexts. I
recall that you have checked this and verified that you are not
doing this.
Well, not quite not possible. The only thing we could come up with
is that Java is running out of memory during saveChanges() and
leaving EOF in an insane state. Your description above fits this
theory exactly. It does not at all fit the "relationships across
editing contexts" theory. Have you checked the app logs of
OutOfMemory and message about heap space?
Yup logs checked. When have no messages about being out of memory or
anything regarding the heap space ( the app has around 500 Meg
assigned to it I believe )
_______________________________________________
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