If you have low traffic, you're best off writing to a sharded counter. Here
are a few strategies I've considered or used in the past and their
tradeoffs:
- Periodic flushing. Has it passed some time since I've last flushed the
value in this key? Yes? Persist this. You can also set this to be
"gene
Hi John,
you mentioned about persisting the memcache counts periodically into
datastore. What's the best practice to do these periodical updates
let's say on a situation when the traffic is very volatile? I've
implemented Twig-persist into my project, so would you like to provide
some additional c
Thanks Ikai, that link was very helpful.
On Apr 8, 6:01 pm, "Ikai L (Google)" wrote:
> Oops. Link is here:
>
> http://gae-java-persistence.blogspot.com/2009/10/optimistic-locking-w...
>
> On Thu, Apr 8, 2010 at 10:00 AM, Ikai L (Google) wrote:
>
>
>
>
>
> > Here's a blog post Max Ross wrote abou
Oops. Link is here:
http://gae-java-persistence.blogspot.com/2009/10/optimistic-locking-with-version.html
On Thu, Apr 8, 2010 at 10:00 AM, Ikai L (Google) wrote:
> Here's a blog post Max Ross wrote about optimistic locking using built in
> features of JDO/JPA
>
>
> On Thu, Apr 8, 2010 at 2:42 A
Here's a blog post Max Ross wrote about optimistic locking using built in
features of JDO/JPA
On Thu, Apr 8, 2010 at 2:42 AM, mscwd01 wrote:
> Thanks John. So basically the process should be:
>
> - Query for the object inside a transaction
> - Update the object counter
> - Commit
>
> - If commit
Thanks John. So basically the process should be:
- Query for the object inside a transaction
- Update the object counter
- Commit
- If commit fails - re-query the datastore for the same object?
Is it possible to just catch the exception and try committing the
object again or will I have to query
