Grr. Just noticed another issue. The cache item that you get the index is not the same item as the lock, so really you need two different cache items, one to make sure you have a unique value for the lock, and the lock itself. The code above is correct, you just need different keys for the first two cache reads.
If you can generate a guaranteed-unique name (maybe the thread ID + time?), you can drop the first cache item and use that as the lock value. This would also prevent the issue with the code above if the lockIndex item is ever evicted and re-read at the same time (thus returning 0 for both), or if it overflows the long. (I honestly don't know if this is iron-clad, but intuitively it seems like it would work with only very minor edge cases.) On Dec 14, 4:08 pm, Andrei Cosmin Fifiiţă <[email protected]> wrote: > Hmmmm, super... > I was thinking of smth like (val mod 2) == 0/1 (true/false), but the lock > reading wasn't safe. > Thanks! > > On 14 December 2010 20:57, Jay Young <[email protected]> wrote: > > > > > > > > > Except return lockIndex should just be return true. > > > -- > > 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%2B > > [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.
