• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: looong saveChanges in a background task
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looong saveChanges in a background task


  • Subject: Re: looong saveChanges in a background task
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 23 Feb 2015 19:01:58 +0000
  • Thread-topic: looong saveChanges in a background task



On 2015-02-23, 10:59 AM, "OC" wrote:

Chuck,

On 23. 2. 2015, at 19:46, Chuck Hill <email@hidden> wrote:

I’d use a different EOF stack but NOT from ERXObjectStoreCoordinatorPool.maxCoordinators which gets shared between requests.  You want one that is not shared and is dedicated to the import task.  

Thanks!

Might you perhaps point me to some docs “how to I set up another EOF stack, for complete dummies“? I've tried to google that (for you previous advice re changing the isolation level/locking discipline), and perhaps it just is not my day or I'm getting older and dumber, but so far I did not find the answer :/

That one is a little harder as you need to create new model groups etc.

For this, just
EOObjectStoreCoordinator osc = new EOObjectStoreCoordinator();
ERXEC ec = ERXEC.new(osc);  // er something like that just typed this from memory


Chuck



Thanks again a big lot,
OC

On 2015-02-23, 10:43 AM, "OC" wrote:
Hello there,
this time, my problem -- at least I hope so -- is going to be simple and straightforward.
My application allows users to import CSV; since it is a lengthy task and sice we need it to stay responsive for others, the import runs in a background task (an ERXLongResponseTask) with a lowered thread priority.
Nevertheless, there still is a problem: if there's a number of imported objects, the threadEC.saveChanges() at the end can take a small eternity. And, given EOF is single-thread, it blocks other threads' access to the DB. Which, alas, rather kills the responsiveness for other users.
One solution would be to use more EOF stacks, but I am told setting ERXObjectStoreCoordinatorPool.maxCoordinators>1 leaks memory as a sieve if one uses BLOBs, and we use them pretty often.
Another solution would be saving changes after importing each 100-odd items, but that brings problems with potential fail of some later save and a need to clean up the previous ones.
Is there another solution to the problem which I have missed? Or do I have to cope with the partial-import-saving?
Thanks a lot,
OC
_______________________________________________
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


 _______________________________________________
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

  • Follow-Ups:
    • Re: looong saveChanges in a background task
      • From: OC <email@hidden>
References: 
 >looong saveChanges in a background task (From: OC <email@hidden>)
 >Re: looong saveChanges in a background task (From: Chuck Hill <email@hidden>)
 >Re: looong saveChanges in a background task (From: OC <email@hidden>)

  • Prev by Date: Re: looong saveChanges in a background task
  • Next by Date: framework load order????
  • Previous by thread: Re: looong saveChanges in a background task
  • Next by thread: Re: looong saveChanges in a background task
  • Index(es):
    • Date
    • Thread