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
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
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
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 mscw...@gmail.com wrote:
Thanks John. So basically the process should be:
- Query for the object inside a transaction
- Update the object counter
- Commit
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) ika...@google.com wrote:
Here's a blog post Max Ross wrote about optimistic locking using built in
features of JDO/JPA
On Thu, Apr 8,
Thanks Ikai, that link was very helpful.
On Apr 8, 6:01 pm, Ikai L (Google) ika...@google.com 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) ika...@google.com wrote:
Here's a blog
