Hadn't really noticed the lockForReading() and unlockForReading() methods. Perhaps that could stop the objects from mutating while we are trying to access them under load. Looking thru the code it seems that various methods like objectsWithFetchSpecification() etc all do a lock() and unlock() already. If our methods were synchronized that make these calls would that accomplish the same thing?
The memory usage is pretty good. The app behaves very well under load - regular garbage collection rhythms. None of our Entities are marked as shared in the model. We have other applications that use the same EOModel. Thanks 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]
