is there any need for queue to complete exactly in sequence ? how much speed do you really need ? may be a simple counter shredded counter to fetch , save and count thing is good enough. and can you describe your PROBLEM instead of PROBLEM IN YOUR SOLUTION OF PROBLEM , there might be different way to achieve the same in app engine....
On Mar 15, 2:28 pm, Iap <[email protected]> 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 [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?hl=en.
