Hi Vik, To be fully transparent, I stopped using JDO and switched to Objectify: much more simple, efficient & transparent than JDO (just check how many issues on this forum with jdo). Learning curve is very quick.
Wih Objectify, if your entities are not too big in size and well indexed to match your queries, you can hope for many tenths of task start (each with its own donor to process) in the course of 30s. I am probably conservative. The advantage of starting additional tasks via API is parallelism: all your donors will be processed simultaneously and then update job is gonna be finished much faster overall. Be careful though if you have global counters updated by many tasks in parallel: you may enter concurrency race issues. But you can post again by then if needed to solve those new issues... regards didier On Oct 25, 2:45 pm, Vik <vik....@gmail.com> wrote: > Hie > > thanks a lot!!! > > So, how about starting a corn job every day say at 00:00 and if time > consumption goes more than 30 sec than scheduling tasks to complete > leftovers. > > I have another question here: The data model for this is: > > BloodDonor_name, blood_group, is_active, active_date > > so query to find donors to be activated ids gonna be: > > select BloodDonor where is_active == false && active_date == <today's > date> > > and update gonna be setting such donors: is_active=true and active_date = > null. > > Any idea how many such entries is safe to consider will be processed within > 30 secs ? > > Thankx and Regards > > Vik > Founderwww.sakshum.comwww.sakshum.blogspot.com > > On Mon, Oct 25, 2010 at 5:53 PM, Didier Durand <durand.did...@gmail.com>wrote: > > > Hi Vik, > > > I would also go with cron job in your case. > > > Concerning the 30s limit, it depends on your requirements in > > computing: > > > a) you can and should probably schedule via api an independent task > > for each separate donor who needs to be processed after your query > > (via cron) told you who needs to be processed today. > > > b) then,for each individual task, if it lasts more than 30s then you > > need to do what I described earlier (i.e pause the current run after > > storing its context and restart it in a new task) > > > regards > > didier > > > On Oct 25, 12:35 pm, Vik <vik....@gmail.com> wrote: > > > Hie > > > > Hmm, so in my case I always know in advance that I need to activate few > > > blood donors every day which were deactivated yesterday. > > > > So, this qualifies for cron jobs. Isn't it ? However, does this 30s limit > > > applies here as well? > > > > Thankx and Regards > > > > Vik > > > Founderwww.sakshum.comwww.sakshum.blogspot.com > > > > On Mon, Oct 25, 2010 at 11:56 AM, Didier Durand <durand.did...@gmail.com > > >wrote: > > > > > Hi, > > > > > I see different purposes for the 2: > > > > > - cron tasks are the tasks I always want to do for sure > > > > - tasks via API are tasks that I schedule programmatically when needed > > > > and triggered by event that I can't predict in advance. > > > > > I see personally 2 other purposes for API tasks: > > > > a) when I run a task and it comes close to the 30s limit, I pause > > > > it, serialize its context and schedule a task with this context. When > > > > the task starts, it's in fact a restart with another 30s credit for > > > > running > > > > b) I also tasks in context of transactions if I want to be sure that > > > > the action of the task is done (i.e datastore writes) even if the > > > > transactions fails -> for example, store errors in datastore for > > > > later analysis for a failing transaction / program, etc. > > > > > regards > > > > didier > > > > > On Oct 25, 6:23 am, Vik <vik....@gmail.com> wrote: > > > > > Hie Thanks for the response. > > > > > > I am confused a bit. If cron job does the scheduling then what Task > > Queue > > > > > does? > > > > > > Thankx and Regards > > > > > > Vik > > > > > Founderwww.sakshum.comwww.sakshum.blogspot.com > > > > > > On Mon, Oct 25, 2010 at 8:51 AM, Didier Durand < > > durand.did...@gmail.com > > > > >wrote: > > > > > > > Hi Vik, > > > > > > > Tasks scheduled via cron.xml is the way I would go: > > > > > >http://code.google.com/appengine/docs/java/config/cron.html > > > > > > > I would schedule a task every minute, make a query on the deadline > > for > > > > > > donors and then do what has to be done. > > > > > > > didier > > > > > > > On Oct 24, 7:11 pm, Vik <vik....@gmail.com> wrote: > > > > > > > Hie Guys > > > > > > > > Our application manages a list of blood donors. Time to time > > these > > > > blood > > > > > > > donors are unreachable so the administrators can mark such blood > > > > donors > > > > > > as > > > > > > > inactive. > > > > > > > > However, these blood donors should be active again after 1 day > > > > > > > automatically. How should we achieve this? ?In regular J2EE apis > > we > > > > can > > > > > > > write scheduler classes to do the same. > > > > > > > What is the option in GAE? Are there any limitations? > > > > > > > > I went through a bit and feel like task queues are the way. But I > > am > > > > not > > > > > > > sure? If yes then for above scenario how should it be done? > > > > > > > > Thankx and Regards > > > > > > > > Vik > > > > > > > Founderwww.sakshum.comwww.sakshum.blogspot.com > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > > > "Google App Engine for Java" group. > > > > > > To post to this group, send email to > > > > > > google-appengine-j...@googlegroups.com. > > > > > > To unsubscribe from this group, send email to > > > > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com> > > > > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com> > > <google-appengine-java%252bunsubscr...@googlegroups.com<google-appengine-java%25252bunsubscr...@googlegroups.com> > > > > > > > . > > > > > > For more options, visit this group at > > > > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Google App Engine for Java" group. > > > > To post to this group, send email to > > > > google-appengine-j...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com> > > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine for Java" group. > > To post to this group, send email to > > google-appengine-j...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
