• 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: Jeff Schmitz <email@hidden>
  • Date: Wed, 30 Jul 2008 23:07:54 -0500
Just remembered I have the PWO book that looks like it will answer most of my questions below, so please disregard them.

Thanks,
Jeff

On Jul 30, 2008, at 12:34 PM, netBrackets wrote:

Thanks, this sounds pretty much like the approach I need, as my updates too will be pretty infrequent, the background thread will make heavy use of EO's, and the results need to be quickly updated to the rest of the site as they are completed. Now to dig into the details, especially concerning using EOGlobalIDs instead of objects, and using the Wonder OSC synchronization, neither of which I've done.

Hope you don't mind a few more questions on this as I dig into the details, starting with a few embedded below...

Thanks,
Jeff

On Wednesday, July 30, 2008, at 08:25AM, "Kieran Kelleher" <email@hidden > wrote: 
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.

Are there examples anywhere of how to do this?

In the task method itself:
- Create a new ObjectStoreCoordinator (use Wonder OSC synchronization
if you want changes to propogate)
Again, any examples of using the Wonder OSC synchronization package? I can never seem to find much documentation on many of the different Wonder packages.

- Create any editing contexts using that single task OSC as a parent
I thinking I should be able to use just one editing context for all the calcs, resetting them at strategic points along the way to free up memory.

- lock and unlock your ec's manually when working with them
I see a lot about locking and unlocking ec's, but haven't found any info on specifics of exactly when. Do and editing context need to be locked before accessing any information from any of its EOs? Will all these locks in anyway lock out my main processing thread(s) if the background thread has its own ObjectStoreCoordinator?

- 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)
Due to the nature of the calculations, I should be able to manually clear out all EC and snapshot info at strategic points along the way, and once cleared I won't need the old data anymore in my calculations. I'm hoping this will keep me clear of hogging too much memory at any one time. But then again, for optimization purposes I'm thinking I could probably load all the data I will need in under 1 gig up front and then just let the calcs rip all the way to the end without needing any trips to the DB. Sound reasonable (if not scalable)?



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


_______________________________________________
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






References: 


 >Re: WOLongResponsePage (From: netBrackets <email@hidden>)






    

  • Prev by Date:
Re: Third Party Jar Project

    • 

  • Next by Date:
Re: Identify a resource in apache webserver directory

    • 

  • Previous by thread:
Re: WOLongResponsePage

    • 

  • Next by thread:
Axis 1.4 + WO 5.3.3 .. yes/no?

    • 

  • Index(es):

      

    • Date
      • 

    • Thread
      • 

    

    •