| Hello,
I’m seeing very occasional stack traces from the wild that start like this:
java.lang.IllegalStateException: Attempt to access an EO that has either not been inserted into any EOEditingContext or its EOEditingContext has already been disposed
at com.webobjects.eocontrol.EOCustomObject.willRead(EOCustomObject.java:1158)
at com.webobjects.eocontrol._EOMutableKnownKeyDictionary$Initializer$_GenericRecordBinding.valueInObject(_EOMutableKnownKeyDictionary.java:570)
at com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
at net.logicsquad.relief.model._Job.jobDate(_Job.java:124)
at net.logicsquad.relief.model.Job.isMultiDay(Job.java:831)
at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) Job.isMultiDay() there is being called in the generation of a page component—it’s the predicate of a conditional in the template. Let me just walk through what happens:
1. A bunch of users will receive a direct action URL (by some non-browser channel, say an email). 2. Some or all of those users will hit the URL where: * A new EC is created with ERXEC.newEditingContext(). * A Job is fetched using a key from the URL: job = Job.fetchRequiredJob(ec, Job.CODE.is(code)). * A page is created using pageWithName(), the Job just fetched is set in that page. * As above, there’s a conditional in the template that calls Job.isMultiDay(). 3. The page is returned to the browser.
Now, this is by no means a massive application, but there’s some modest concurrency during the process above: multiple users will hit that DA, potentially changing and saving properties of the Job, and it’s not at all inconceivable that the creator of the original Job object will change her mind and even delete it at any point during the process. Just to make things super-interesting, we’re also running ERJGroupsSynchronizer across several instances.
So… what are the possibilities here? Given we create an EC per request, and fetch the Job straight into it, under what circumstances can that error message be true?
|