Nope, not using transactions. On the Python side, we read the entity,
update a few of its properties, put(), then return to the browser, which
then invokes a request on a Java servlet, which reads the entity using
lookup-by-key.
Thanks Chad, thanks Jeff. I'm going to do that versioning scheme I
mentioned above, put some load on it, and make sure I'm always getting the
same version.
--Jon
On Tuesday, November 1, 2016 at 1:37:49 PM UTC-4, Chad Vincent wrote:
>
> Then no, you aren't caching on the Java side.
>
> Are you (or NDB) using transactions? If so, then make sure you schedule
> your hand-off to Java after the transaction has committed?
>
> On Monday, October 31, 2016 at 10:54:28 PM UTC-5, Jonathan Munson wrote:
>>
>> I don't believe I use Objectify, unless it's used transparently by the
>> Java Datastore API. Here's a snippet of code that shows how I use the API:
>>
>> DatastoreService datastore =
>> DatastoreServiceFactory.getDatastoreService();
>> Key key = KeyFactory.stringToKey(serKey);
>> try {
>> Entity entity = datastore.get(key);
>>
>> Is there any caching involved here, on the Java side? If there is, then
>> what you and Jeff say is definitely the problem.
>>
>>
>> On Monday, October 31, 2016 at 11:47:12 PM UTC-4, Chad Vincent wrote:
>>>
>>> Just to be 100% clear (sorry I keep double-posting, it's a bad habit):
>>>
>>> Java and Python modules in the same app share Memcache, which is just a
>>> giant Key-Object map.
>>>
>>> Objectify uses different Memcache keys than NDB. I don't remember Ofy's
>>> format, and can't find NDB's, so let's just say
>>> [ofy-agR0ZXN0cgkLEgNGb28YGQw] vs. [ndb-agR0ZXN0cgkLEgNGb28YGQw]. So when
>>> you do an NDB write, [ndb-agR0ZXN0cgkLEgNGb28YGQw] gets invalidated and
>>> [ofy-agR0ZXN0cgkLEgNGb28YGQw] is stale.
>>>
>>> You need to either add a wrapper to NDB to ensure you're invalidating
>>> the Objectify cache, too, or disable *at least* Objectify's caching for
>>> that entity type.
>>>
>>> On Monday, October 31, 2016 at 10:40:18 PM UTC-5, Chad Vincent wrote:
>>>>
>>>> > When I write an entity on the Python side, NDB invalidates the
>>>> entity's cache entry (according to the docs),
>>>>
>>>> I think you missed the *key* part of Jeff's response. Objectify and
>>>> NDB do not use the same entries in Memcache. So while NDB on Python
>>>> invalidated *its* cache entry, Objectify used a different namespace and
>>>> thus the Objectify cached entry is still there.
>>>>
>>>> On Monday, October 31, 2016 at 8:33:19 PM UTC-5, Jonathan Munson wrote:
>>>>>
>>>>> I now think that caching shouldn't be an issue. When I write an entity
>>>>> on the Python side, NDB invalidates the entity's cache entry (according
>>>>> to
>>>>> the docs), forcing (strongly consistent) reads to get the value from the
>>>>> Datastore service. So a lookup-by-key read from the Java side should get
>>>>> the most recently written value, according to Chad.
>>>>>
>>>>> I think I'm going to have to put a version counter on the entity,
>>>>> which I'll increment on the Python side, then pass to the Java module so
>>>>> it
>>>>> can check the value of it when it gets the entity from the Datastore.
>>>>> "Trust but verify."
>>>>>
>>>>> --Jon
>>>>>
>>>>> On Monday, October 31, 2016 at 8:56:18 PM UTC-4, Jeff Schnitzer wrote:
>>>>>>
>>>>>> There is no standard way of storing entities in memcache. Objectify
>>>>>> uses its own namespace and uses the string version of Keys as the cache
>>>>>> key. I don’t know what NDB does.
>>>>>>
>>>>>> Cache invalidation is already a hard problem (that and naming things,
>>>>>> as they say). If you want to access data from both python and java, best
>>>>>> to
>>>>>> disable the memcache behavior of both NDB and Objectify (don’t put
>>>>>> @Cache
>>>>>> on anything shared).
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>> On Mon, Oct 31, 2016 at 2:01 PM, Jonathan Munson <jpmu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks, Chad. Re your comment about caching, I am using NDB on the
>>>>>>> Python side, which I thought used memcache automatically. So I guess I
>>>>>>> am
>>>>>>> using caching, but I thought that modules in the same project (mine
>>>>>>> are)
>>>>>>> shared memcache. Is that not true if one module is Python and the other
>>>>>>> Java?
>>>>>>>
>>>>>>>
>>>>>>> On Monday, October 31, 2016 at 3:07:43 PM UTC-4, Chad Vincent wrote:
>>>>>>>>
>>>>>>>> Also, make sure you aren't doing deferred writes or starting the
>>>>>>>> Java request before your Python transaction closes.
>>>>>>>>
>>>>>>>> On Monday, October 31, 2016 at 2:05:06 PM UTC-5, Chad Vincent wrote:
>>>>>>>>>
>>>>>>>>> Yes. Consistency is handled by the database layer, not the
>>>>>>>>> application runtime.
>>>>>>>>>
>>>>>>>>> HOWEVER, if you are caching entities (Objectify, etc.) you either
>>>>>>>>> need to ensure your Memcache keys are identical or disable caching
>>>>>>>>> for
>>>>>>>>> those entities. Otherwise the Java cache may return a stale result
>>>>>>>>> because
>>>>>>>>> the Python module didn't clear/update the entity on write.
>>>>>>>>>
>>>>>>>>> On Monday, October 31, 2016 at 8:41:07 AM UTC-5, Jonathan Munson
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We have an app wherein a Datastore entity is written to by a
>>>>>>>>>> Python module (using NDB), and then in an immediately following
>>>>>>>>>> request,
>>>>>>>>>> read from, using the entity's key, by a Java module. In a situation
>>>>>>>>>> where
>>>>>>>>>> the app was heavily loaded, it seemed like the Java module was
>>>>>>>>>> reading
>>>>>>>>>> stale data. The Datastore documentation says that lookup-by-key
>>>>>>>>>> requests
>>>>>>>>>> are strongly consistent, but does that apply even when writes are
>>>>>>>>>> from a
>>>>>>>>>> Python module and reads are from a Java module?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> --Jon
>>>>>>>>>>
>>>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Google App Engine" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to google-appengi...@googlegroups.com.
>>>>>>> To post to this group, send email to google-a...@googlegroups.com.
>>>>>>> Visit this group at https://groups.google.com/group/google-appengine
>>>>>>> .
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/google-appengine/3d0c204d-f2d4-4cb7-8db0-26c9db942e6a%40googlegroups.com
>>>>>>>
>>>>>>> <https://groups.google.com/d/msgid/google-appengine/3d0c204d-f2d4-4cb7-8db0-26c9db942e6a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/13bc6dac-f1ca-48a8-8ad1-999b70e514c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
