Chuck, you are the MAN! I removed the relationship between my lookup entity back to the many-to-many entity and the issue is gone. I still don't understand why all those back-references were in memory in the first place, or why webobjects felt they had to be updated. Does WO always try to keep the whole database in memory, and what if your data is larger than what can fit into RAM?
As always, thanks for all the insight! Greg On Thu, Jul 8, 2010 at 11:49 AM, Chuck Hill <[email protected]>wrote: > > On Jul 8, 2010, at 8:14 AM, Greg Lappen wrote: > > > I am using some Wonder frameworks, but I don't think I am pulling it in > globally. My thread dump doesn't show any wonder classes in the mix. > > Lacking this fix would certainly make the problem worse. > > > > Chuck, can you elaborate more on the back-pointing relationships issue? > You said it might be a modelling issue - does that mean that EO has > problems when a one-to-many relationship gets too large? > > It wants to manage the entire relationship in memory for validation and to > maintain object graph integrity. So if you are adding to / removing from a > very large relationship there can be significant overhead. This is > particularly a problem if you have modeled the reverse relationship from a > lookup entity (table) back to the entity referring to the lookup data. > Usually this relationship is not used and simply adds a large performance > overhead to operations. It is easy enough to fetch the data when you need > it, far better than modeling this. > > > Chuck > > > > > Thanks to everyone for the help! > > > > On Thu, Jul 8, 2010 at 11:11 AM, Mike Schrag <[email protected]> wrote: > > Are you using Wonder? I seem to recall that Anjo fixed a pretty huge > performance problem in removeObject a year or two ago ... > > > > ms > > > > On Jul 8, 2010, at 10:58 AM, Chuck Hill wrote: > > > > > Hi Greg, > > > > > > Is the database content (not the schema) the same for both deployments? > Could one have a very large number of back-pointing relationships that the > other does not have? If so, I will suggest that you have a modelling issue. > If not... puzzling. > > > > > > Chuck > > > > > > > > > On Jul 8, 2010, at 6:46 AM, Greg Lappen wrote: > > > > > >> Hi all, > > >> > > >> I am running into a bizarre issue with our WebObjects Application. I > have searched the lists for quite a while, but could not find a case where > someone had the same problem. > > >> > > >> What is even stranger is that our application is deployed on two > different servers, both with WebObjects 5.4.3 and in one environment the > issue occurs, and not in the other. > > >> > > >> What I see is that calling editingContext.saveChanges() is returning > immediately in one case, and hanging for 20 seconds in the other case. It's > not really "hanging" - the CPU is pegged at over 100%, and taking thread > dumps during that 20 seconds shows something like this: > > >> > > >> "WorkerThread3" prio=5 tid=0x000000010296a800 nid=0x1519b2000 runnable > [0x00000001519af000] > > >> java.lang.Thread.State: RUNNABLE > > >> at java.lang.reflect.Array.newInstance(Array.java:52) > > >> at > com.webobjects.foundation._NSCollectionPrimitives.copyArray(_NSCollectionPrimitives.java:123) > > >> at > com.webobjects.foundation.NSArray.objectsNoCopy(NSArray.java:356) > > >> at > com.webobjects.foundation.NSMutableArray._removeObject(NSMutableArray.java:225) > > >> at > com.webobjects.foundation.NSMutableArray.removeObject(NSMutableArray.java:247) > > >> at > com.webobjects.foundation.NSMutableArray.removeObjects(NSMutableArray.java:399) > > >> at > com.webobjects.foundation.NSMutableArray.removeObjectsInArray(NSMutableArray.java:285) > > >> at > com.webobjects.foundation._NSArrayUtilities.arrayExcludingObjectsFromArray(_NSArrayUtilities.java:173) > > >> at > com.webobjects.eoaccess.EODatabaseContext.recordChangesInEditingContext(EODatabaseContext.java:5943) > > >> at > com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:373) > > >> at > com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192) > > >> at > net.paperfree.lightbeam.model.LPFile.setFileData(LPFile.java:102) > > >> > > >> Seems like the EODatabaseContext is doing some housekeeping before > executing the SQL....here's the Java code in question: > > >> > > >> public class LPFile extends _LPFile { > > >> .... > > >> .... > > >> public synchronized void setFileData(NSData fileData) throws > IOException { > > >> // Update forms by deleting existing ones, then adding new ones > > >> for (int i=lpFileForms().count()-1; i>=0; i--) { > > >> final LPFileForm lpFileForm = (LPFileForm) > lpFileForms().objectAtIndex(i); > > >> this.removeFromLpFileForms(lpFileForm); > > >> editingContext().deleteObject(lpFileForm); > > >> } > > >> > > >> // Get new form list via SOAP call > > >> Element docInfoElm = > LPServer.threadLocal().exportDocumentInfo(this); > > >> List formElms = formsElm.getChildren("form"); > > >> for (int i = 0; i < formElms.size(); i++) { > > >> Element formElm = (Element) formElms.get(i); > > >> LPFileForm lpFileForm = new LPFileForm(); > > >> > > >> // extract data from xml, put into lpFileForm > > >> > > >> // Setup relationships to lpForm and lpFile > > >> lpFileForm.setLpForm(lpForm); > > >> lpFileForm.setLpFormID(lpForm.id()); > > >> lpFileForm.setLpFile(this); > > >> lpFileForm.setLpFileID(this.fileID()); > > >> > > >> this.addToLpFileForms(lpFileForm); > > >> editingContext().insertObject(lpFileForm); > > >> } > > >> > > >> editingContext().saveChanges(); > > >> } > > >> .... > > >> .... > > >> } > > >> > > >> Does the above code have anything obviously wrong with it? It's > basically clearing a one-to-many relationship, then re-populating it. I > call this.addToLpFileForms() because I want the relationship updated in > memory as well as in the database. > > >> > > >> Any insight would be hugely appreciated. > > >> > > >> Thanks, > > >> > > >> Greg > > >> _______________________________________________ > > >> 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/chill%40global-village.net > > >> > > >> This email sent to [email protected] > > > > > > -- > > > Chuck Hill Senior Consultant / VP Development > > > > > > 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 protected]) > > > Help/Unsubscribe/Update your Subscription: > > > > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com > > > > > > This email sent to [email protected] > > > > > > -- > Chuck Hill Senior Consultant / VP Development > > 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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
