If your import process is running in a woa that is concurrently
serving many users, you may find that creating a new
EOObjectStoreCoordinator and then doing your eof intensive tasks in
that can help performance.
It can be as simple as
EOObjectStoreCoordinator osc = new EOObjectStoreCoordinator();
EOEditingContext ec = new EOEditingContext( osc );
(If using Wonder, then use the ERXEC factory)
In one app I have, I run automated scheduled tasks and admin import/
data processing tasks in a different EOF stack and it has stopped the
app becoming sluggish and unresponsive along with improved processing
time while running those long EOF intensive tasks.
YMMV,
Regards, Kieran
On Apr 25, 2007, at 3:03 PM, Scott Winn wrote:
Thanks Chuck. I will give it a look.
I still don't know what the problem was, but I have updated
FrontBase and its plugin (I was a few point releases behind). The
release notes for some of those points included delete fixes. I
also added EC.undoManager().removeAllActions(). I haven't disposed
of the editing context yet, but I may once I have checked the
performance results from my most recent run.
I put the same data back through the importer and no DB crash this
time, although things still seemed very slow. More than 1/2 an
hour to process about 1 MB of data seem like a bit much. I checked
free memory just prior to doing the delete and it never dips below
74%.
Scott
On Apr 24, 2007, at 10:32 PM, Guido Neitzer wrote:
On 24.04.2007, at 20:59, Chuck Hill wrote:
The first thing I would do is to add this line:
recordContext .undoManager().removeAllActions();
The next thing I would do (voodoo or not) is to periodically
dispose of recordContext and create a replacement. In the past
that was vital.
It still is. It helps. Not necessarily for performance but
normally for memory usage. I normally do bulk import in batches
of up to 500 objects per batch, then save and dispose the
editingContext, set it to null and create in new one in the next
batch. Also for bulk updating of EOs.
That works well for my importers.
If you need to resolve relationships during import, pre-fetching
the relationships can make a huge difference.
As as you are deleting, I have a DeletePrefetcher class that may
be of use. I originally wrote this as a bug workaround, but it
might also make the fetches more efficient. It is part of our
GVCEOFExtensions framework that you can get from http://
sourceforge.net/projects/gvcsitemaker
To save you the download, I have temporarily stuck a copy here:
http://www.gvcsitemaker.com/chill/files/deleteprefetcher.java
Chuck
--
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/kieran_lists%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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]
