Re: 20 Second Delay on editingContext.saveChanges()
Re: 20 Second Delay on editingContext.saveChanges()
- Subject: Re: 20 Second Delay on editingContext.saveChanges()
- From: Chuck Hill <email@hidden>
- Date: Thu, 8 Jul 2010 12:19:06 -0700
On Jul 8, 2010, at 10:35 AM, Greg Lappen wrote:
> 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?
No, it does not try to keep it all in RAM, only the parts that are currently in active use in your application. But when altering to-many relationships it does want some representation (faults are OK IIRC) of the EOs in memory. So altering a very large relationship can be expensive. Anjo's fix to removeObject() increases the size at which cost starts to be felt.
Which version of WO are you using?
Chuck
> As always, thanks for all the insight!
>
> Greg
>
> On Thu, Jul 8, 2010 at 11:49 AM, Chuck Hill <email@hidden> 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@hidden> 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@hidden)
> > >> Help/Unsubscribe/Update your Subscription:
> > >>
> > >> This email sent to email@hidden
> > >
> > > --
> > > 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@hidden)
> > > Help/Unsubscribe/Update your Subscription:
> > >
> > > This email sent to email@hidden
> >
> >
>
> --
> 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
>
>
>
>
>
>
>
>
--
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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