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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
