Yes, obviously I can't use task names because of the 7-day expiration; I just happened to be testing something else on the dev server when I noticed that it behaved the way I wanted.
In my case the unreliability of memcache isn't too much of a concern for two reasons. First, I expect the tasks be executed relatively quickly--within a few hundred milliseconds--and hopefully memcache can be relied upon for at least that long. Second, there's no real harm if my tasks get executed more than once. I just opened a new issue on this, if you want to go star it: http://code.google.com/p/googleappengine/issues/detail?id=2459 Vince On Tue, Dec 1, 2009 at 5:24 PM, James H <james.hollier...@gmail.com> wrote: > Sorry, I was writing my 2nd reply prior to seeing yours...but I mean't > don't specify a Task Name in order to free yourself from the > rediculous 7-day rule (what good is that?). So really since memcache > is not a good choice for sensitive mutable data such as a mutex, you'd > have to implement your own as I suggested. I'll be curious to hear > other alternatives since this would be a common requirement in apps! > > On Dec 1, 4:17 pm, James H <james.hollier...@gmail.com> wrote: > > Also, the nature of memcache is such that it would not be reliable for > > a mutex (since objects can be removed by the system at any time > > regardless if Task N is running), hence the potential for duplicate > > task entries. > > > > On Dec 1, 4:08 pm, James H <james.hollier...@gmail.com> wrote: > > > > > > > > > Vince, shouldn't you use an un-named Task queue (to avoid Naming rules > > > mentioned) but query your own datastore semaphore prior to adding to > > > the queue. This way when task N runs it manages the semaphore (a > > > Entity) to implement a mutex begin/end sequence. I believe this > > > implies that task N will in fact run 3 transactions: #1 - mutex begin > > > (create Entity), #2 - work for N, and #3 - mutex end (remove Entity). > > > > > Anyhow assuming your logic to trigger a new Task N can incorporate the > > > criteria for mutex exists, then what would keep this from working? > > > > > On Dec 1, 2:37 pm, Vince Bonfanti <vbonfa...@gmail.com> wrote: > > > > > > BTW, I've noticed that the dev server actually behaves the way I > would like > > > > it to. It only throws a "Task name already exists" exception while > the task > > > > is queued; as soon as the task runs it allows you to queue up another > task > > > > with the same name. > > > > > > I guess I'll just open a feature request on this in the issue > tracker. > > > > > > Vince > > > > > > On Tue, Dec 1, 2009 at 11:39 AM, Vince Bonfanti <vbonfa...@gmail.com> > wrote: > > > > > I'm trying to solve the following problem using task queues: > > > > > > > 1. Queue a task to perform some action "N". > > > > > 2. Until action N has been performed, don't allow any other tasks > to be > > > > > queued that also perform action N. > > > > > 3. As soon as action N has been performed, immediately allow > other tasks > > > > > to be queued to perform action N (repeat from step 1). > > > > > > > Using task names almost accomplishes what I need, except that at > step 3 it > > > > > will be at least seven days before another task can be queued to > perform > > > > > action N, when I need it to be allowed immediately: > > > > > > > "This (task names) provides a lightweight mechanism for ensuring > > > > > once-only semantics. Once a Task with name N is written, any > subsequent > > > > > attempts to insert a Task named N will fail. Eventually (at least > seven days > > > > > after the task successfully executes), the task will be deleted and > the name > > > > > N can be reused." > > > > > > > I've thought of different ways to solve this, most likely by using > a > > > > > memcache flag as a semaphore. But, it would be nice if the task > queue API > > > > > could support this natively, maybe by adding a "reuse time" or > "exclusion > > > > > time" parameter when setting the TaskOptions name parameter. > > > > > > > Any thoughts on this? > > > > > > > Vince- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > -- > > 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.
