You might be better off figuring out if you can design your code so that it does not need locking.
You could make it so that whichever client submits processed work from the queue last gets priority.. the other clients work that got returned earlier is just discarded. This way, work could simply be submitted with work entities having explicit key_names and just being .put() to the datastore. Either way, you can easily set up a method so that either, first-submitted or most recently-submitted work is given priority. Granted I'm not clear on exactly what sort of work is getting processed from your queue. It just seems like you'll expend more resources trying to be exact by not having more than one client grab the same workload.. which will then slow down the apps performance and gobble up more resources. On Mon, Mar 15, 2010 at 5:28 AM, Iap <iap...@gmail.com> wrote: > Hi, > > I think that I do require "instance locking" for the DataStore to solve the > integrity problem in my scenario. > > It's a long story but I will try to put it as brief as possible: > 1) Suppose there is a FIFO queue, Q. > 2) To consume the queue, there are many clients ( say, the flash movie in > the browser) connect to the GAE for consuming the queue. > 3) For every consumption from the client side, the dispatching CGI has to > 3.1) query the DataStore for all entries, > 3.2) sorting the entries to get the 1st item in the queue. > 3.3) mark the item been consumed. then, the item moves to its next > phase. > 3.4) update the queue.(remove the item from queue) > > The problem will happen if : > a) when client-A requests for consumption, the dispatching CGI handles the > request. but the DataStore got stuck in doing 3.2 on occasion. > b) During that stuck period, client-B requests for consumption, this time, > the DataStore runs very well, without any delay. > c) The client-A and client-B reaches the 3.3 at the same time, they both > got the same item in the queue. That is the problem. > Either the client-A or the client-B overrides the other's effort to > the same item in queue. > > I am thinking about to utilize the memcache to do the locking, but I was > told that the memcache is not guaranteed. > I also assume that the "locking" should not depends on the DataStore which > is the origin of uncertainty. > (aka to put a BooleanProperty "LOCK" to the instance) > The other suggestion is the "transaction". I encountered many exceptions > while putting the step 3.2, 3.3 to a transaction. > Such as "nested transaction is not allowed","Cannot operate on different > entity groups","must be an ancestor...". > Because the transaction has so much limitation, it seems not realistic to > use transaction. > Whereas to lock/release the entry (object) is simpler and more concise. > It would be nice if the item is lock-able, or the queue is lock-able. > > Iap > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
