|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
My app has a batch loading function where a user can upload a tab-delimited file which is then parsed and EOs created and saved from the contents. When I originally wrote the batch loading function, I was passing the user's session().defaultEditingContext() to do the inserting/fetching/saving. That worked fine. I was able to parse a file with 40K+ record and create all the appropriate EOs no problem. Then I thought it might be a better idea to have the batch loader object use its own Editing Context and also use a nested editing context where each inidividual record would be parsed and an EO created in the child context that would then save to the parent EC (to get the validations), and then every 25 lines the parent EC would itself save to the underlying objectstore and on into the database. In my current configuration, for each record a new child EC is created while the parent EC exists for the duration of the load. The Child EC is locked as soon as it is created and when I'm done with the line I call: childEC.unlock(); childEC.dispose(); childEC = null; So this goes on and on, but the application slows down and eventually it crashes with java.lang.OutOfMemoryError. That was a head-scratcher. Eventually after researching the lists, I tried something that had worked for someone else. After the save of the parentEC, I call parentEC.rootObjectStore().invalidateAllObjects(). My assumption, based on my limited knowledge, was that during the batch load, all the EOs I was creating were hanging around in the underlying ObjectStore rather than being garbage collected and that eventually the memory just filled up. This solution did work - no out of memory error. So my question is, is the defaultEditingContext doing something to prevent this memory hogging that I'm just not aware of? Because, again, I did not have to invalidateAllObjects in order to get everything to work when all I did was use the defaultEditingContext... ===== Jason McInnes 2 Degrees Cell: 206.849.3680 Email: email@hidden __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail _______________________________________________ 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
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.