I'm not sure I follow the first part of your response--are you mixing up "queue names" and "task names"?
But, yes, implementing a mutex via memcache works (I've already tested it), but there are two things I don't like about this approach: 1) There's additional overhead of using memcache (about 15ms per memcache call, though I've measured up to 90ms). 2) It makes my code more complex than it needs to be, considering that the task queue API already supports almost everything I need. Vince On Tue, Dec 1, 2009 at 5: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 - > > -- > > 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]<google-appengine-java%[email protected]> > . > 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 [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.
