According to the docs for EOSharedEditingContext: In multithreaded applications, shared objects can be used safely by many threads at once. Shared editing contexts use NSMultiReaderLocks to maintain thread safety. The methods objectsWithFetchSpecification bindObjectsWithFetchSpecification, faultForGlobalID, and objectForGlobalID are thread safe, but the context must be locked before using any other shared context API.
We use EOUtilities.objectWithPrimaryKey() which uses objectsWithFetchSpecification() internally. Dov On 12/14/08 8:42 PM, "Lachlan Deck" <[email protected]> wrote: > Hi Dov, > > On 15/12/2008, at 12:11 PM, Dov Rosenberg wrote: > >> We are using WO 5.4.3. We are also use Project Wonder. Not sure how to >> figure out the Project Wonder version, but it is the latest as of >> November. > > ok > >> I am actually suprised that my stacktrace doesn¹t have any Project >> Wonder >> classes in it since we are extending ERXEC and such. Perhaps because >> this >> editing context is the EOSharedEditing Context. > > Correct. EOSharedEditingContext does not extend ERXEC. But that's a > different issue. > >> Here are the decompiled >> lines of WO code that the stack trace is referring to: >> >> com.webobjects.eoaccess.EODatabaseContext.java >> public void _fireArrayFault(Object fault) { >> EOAccessArrayFaultHandler handler = >> (EOAccessArrayFaultHandler)EOFaultHandler.handlerForFault(fault); >> if(handler == null) throw new >> IllegalStateException("Cannot fire >> array fault with a null handler."); >> .... >> >> MyCode.java >> NSArray roles = user.securityRoles(); if (roles != null) >> { for >> (int i = 0; i < roles.count(); ++i) { <--- roles.count() starts the >> stacktrace. User.securityRoles() returns data under the same user >> while not >> under concurrent load. The roles array appears to be valid since it >> passes >> the NULL check > > Yeah - the problem is that for some reason (yet unknown) the array > fault is botched. > I'd suggest pinging Pierre on this one. > > The questions you skipped though could be helpful: > - memory usage? > - anything special about the entities triggering this? (e.g., > inheritance) Is it marked as shared in the model? > > - are you using locking? Or have you tried using locking? i.e., ERXEC > auto-locking does *not* apply to EOSharedEditingContext. > > EOSharedEditingContext.defaultSharedEditingContext().lockForReading(); > try > { > > } > finally > { > > EOSharedEditingContext.defaultSharedEditingContext().unlockForReading(); > } > > >> On 12/14/08 6:51 PM, "Lachlan Deck" <[email protected]> wrote: >> >>> On 14/12/2008, at 4:10 AM, Dov Rosenberg wrote: >>> >>>> We don¹t throw these errors if we try to debug and step thru the >>>> code only >>>> under load. These particular EO¹s come from the infamous >>>> SharedEditingContext. We use the SharedEditingContext because this >>>> portion >>>> of the app is READONLY and it allows us to share the data between >>>> sessions >>>> instead of having to refetch is for every session. >>> >>> Memory usage? Any particular entities that trigger this? (e.g., any >>> inheritance). >>> How are you faulting the data? Locking? >>> >>>> Any thoughts would be appreciated >>> >>> with regards, >>> -- >>> >>> Lachlan Deck >>> >> > > with regards, > -- > > Lachlan Deck > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
