• 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: WOLongResponsePage
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WOLongResponsePage


  • Subject: Re: WOLongResponsePage
  • From: Kieran Kelleher <email@hidden>
  • Date: Wed, 30 Jul 2008 09:25:55 -0400

I have an app that does very long tasks like this a few times a week. The tasks I have a *very* EOF intensive, as in hammering the database usually for a very long time (4 to 24 hours)

Here is approach I use:

Create a Callable (or Runnable) class for the task.
Create setters/getters for any initial variables you need to pass in. For EnterpriseObjects, just pass in the EOGlobalIDs, not the objects themselves.
In the task method itself:
- Create a new ObjectStoreCoordinator (use Wonder OSC synchronization if you want changes to propogate)
- Create any editing contexts using that single task OSC as a parent
- lock and unlock your ec's manually when working with them
- depending on how much EO's you are fiddling with, memory management can be challenging, so recycling ec's, and, dare I say it, resorting to checking available memory and forcing garbage collection when memory almost exhausted (some will cringe at this, but extreme EOF just sucks memory and does not let go fast enough ... depending on the conditions)


Tips
- Surround the task with a try/catch to get any errors
- Send an email to the user (if user initiated), or admin (if necessary) notifying them of success, failure or error when task is done (or error is thrown).
- Using log4j smtp appender for ERROR level is good too to ensure errors in anonymous tasks are alerted to admin/devs promptly.



On Jul 30, 2008, at 12:23 AM, Jeff Schmitz wrote:

Hello,
I have the need to kick off a VERY long (i.e. possibly up to 8-10 hour) background task that before it's through fetches most of the contents of the database (via EO's of course) and performs calculations on the data and saves the calculated values back to the EOs many times during the process. And oh, I'd like to have the results available to the rest of my app as they are saved by the background task.


Currently btw, I do this with a java thread and don't really use EOs, and I just return a page immediately after the thread is kicked off, i.e. I don't really care about a status page reloading for 8 hours as I'm the only user that actually kicks off this process.

My first question is, now that I'm using EOs throughout my app (including the background process) is there any reason to use the WOLongResponsePage if I still don't care about the status page? If so, there seems to be a dearth of information on exactly how to use such a component. All I can really find is a very terse API doc, and a few mentions of its existance on the wiki. Any examples out there anywhere?

I'll save my context locking and memory flushing questions until after I've researched the subject a little more. From what I can tell though, I'll want to create a new editing context for the background thread (not sure about needing an independent Object store coordinator for the background process, but I don't think so), so that's a start.

Finally, anything in project Wonder that can help me? I did run across this:

http://webobjects.mdimension.com/wonder/api/er/extensions/concurrency/class-use/ERXLongResponseTask.html#er.extensions.concurrency

but again, very terse docs.

Thanks,
Jeff

_______________________________________________
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: WOLongResponsePage
      • From: Kieran Kelleher <email@hidden>
References: 
 >WOLongResponsePage (From: Jeff Schmitz <email@hidden>)

  • Prev by Date: Re: WOLongResponsePage
  • Next by Date: Re: web objects 5.4.2 URL parsing errors
  • Previous by thread: Re: WOLongResponsePage
  • Next by thread: Re: WOLongResponsePage
  • Index(es):
    • Date
    • Thread