• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Back To Basics : Databases Active Editing Context
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 16:53:29 -0700

Hi Owen,


On Jul 3, 2008, at 4:36 PM, Owen McKerrow wrote:

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 ?

No, it locks it some time after saveChanges() is called. saveChanges() first needs to do some housekeep and once that is done, it locks the DB context. This keeps the length of time it has it locked to a minimum.



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.




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.

The only other thing I can see is some odd exception getting thrown during saveChanges() that is preventing the DB context from resetting the active EC to null. But, I think Pierre and I looked at it and there is a try...finally block that should prevent this.



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 ).

Definitely related to concurrency. Though that knowledge is of little help.



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 ?

Correct.


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 )


You might want to verify that somehow. Maybe attach Shark or jdb or something to it.


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


  • Follow-Ups:
    • Re: Back To Basics : Databases Active Editing Context
      • From: "M.Y. Tjoe" <email@hidden>
References: 
 >Back To Basics : Databases Active Editing Context (From: Owen McKerrow <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Chuck Hill <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Owen McKerrow <email@hidden>)

  • Prev by Date: Re: DB uniqueness constraints and dealing with them
  • Next by Date: Re: DB uniqueness constraints and dealing with them
  • Previous by thread: Re: Back To Basics : Databases Active Editing Context
  • Next by thread: Re: Back To Basics : Databases Active Editing Context
  • Index(es):
    • Date
    • Thread