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 18:54:07 -0700
On Jul 3, 2008, at 6:37 PM, M.Y. Tjoe wrote:
Hi Chunk and Owen,
Chunk?
Sorry to interrupt you guys....
On 04/07/2008, at 9:53 AM, Chuck Hill wrote:
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.
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.e.
ecA saving changes (after housekeep) and locked DBcontext.
ecB don't know DBcontext being locked and trying to access it.
ecB throws exception and wander why me is not the active active ec
of DBcontext.
Is WO application be able to handle two ec save changes inside one
RR-loop? do you recommend?
Yes, but they are handles consecutively, not concurrently.
2) How/When does a EC become the databases active editing
context ?
Someplace inside of saveChanges() after / when it locks the
DBContext
What about fetching data from DB, does ec lock DBcontext as well?
yes.
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
Is there any ways to release DBcontext from ec when this exception
happens?
This should happen automatically. I don't even know if an exception
is causing this. That is just a wild guess.
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