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 - -- 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.
