Documentation Question: Closure memoization

[Scott]

http://gaelyk.appspot.com/tutorial/app-engine-shortcuts#async-memcache

states:

"Note: Invocations are stored in memcache only for up to the 30
seconds request time limit of App Engine."

What does this mean? Does it mean they are only stored in memcache for
30 seconds??

Because there is no limit on the amount of time something is stored in
memcache:

http://code.google.com/appengine/docs/java/memcache/overview.html

"By default, values stored in memcache are retained as long as
possible."
"Under rare circumstances, values may also disappear from the cache
prior to expiration..."

[Guillaume Laforge]

Hi Scott,

The closures are instanciated in your groovlets, and somehow, their specific instance is used as a key in memcache.

The lifespan of those closures are the lifespan of the request, so a next invocation would yield a different closure instance anyway.

So it's useless to keep those memoized invocations in the cache longer than the duration of the request, as the information would not be accessible anymore by the "newer" closures of a new request.

That said, I think now the request time limit has been up-ed to 60 seconds, so I'll increase the lifespan of that invocation cache accordingly.

If you want to keep something in the cache beyond the lifespan of a request, you should do it explicitely.

You can use the URL routing caching to cache groovlet or template fragments, or for values, you can use the memcache service explicitely.

Guillaume

--
You've received this message because you've subscribed to the Gaelyk Google Group.
To send an email to the group, please write to: gae...@googlegroups.com
To unsuscribe from this group: gaelyk+un...@googlegroups.com
To show more options: http://groups.google.fr/group/gaelyk?hl=en

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Twitter: @glaforge

Google+: http://gplus.to/glaforge

[Guillaume Laforge]

On Wed, Feb 8, 2012 at 11:59, Guillaume Laforge <glaf...@gmail.com> wrote:

[...]

That said, I think now the request time limit has been up-ed to 60 seconds, so I'll increase the lifespan of that invocation cache accordingly.

Actually, in the code, it's already 60 seconds.

So it's just the documentation that needs an update here.

[Scott]

hmmm, seems kind of pointless then, no? I mean, why would you make
the same call twice in a request? unless you are trying to leverage
other threads?
And for that matter, why even use memcache? why not just local
memoization so you don't have the latency of the RPC calls?

That being said, why not pass a parameter to memoize to be used as the
key?

On Feb 8, 3:23 am, Guillaume Laforge <glafo...@gmail.com> wrote:

> On Wed, Feb 8, 2012 at 11:59, Guillaume Laforge <glafo...@gmail.com> wrote:
> > [...]
> > That said, I think now the request time limit has been up-ed to 60
> > seconds, so I'll increase the lifespan of that invocation cache accordingly.
>
> Actually, in the code, it's already 60 seconds.
> So it's just the documentation that needs an update here.
>
> --
> Guillaume Laforge
> Groovy Project Manager
> SpringSource, a division of VMware
>
> Blog:http://glaforge.appspot.com/

> Twitter: @glaforge <http://twitter.com/glaforge>
> Google+:http://gplus.to/glaforge

[Guillaume Laforge]

Hi Scott,

The current closure memoization is indeed perhaps not ideal, or at least not as useful as it should.

I had a use case at some point where I was reusing the result of a query... but using even a some local variables or some maps of some kind would have been enough.

But yes, perhaps something a little bit different with the use of a reusable key might be interesting.

At this point, I'm more interested in introducing query result caching as a new feature, which would prove much more useful.

And otherwise, for other cases, I've got the impression that direct use of memcache is probably better, as I can't really imagine all the possible use cases of what people want to cache and have reusable across requests.

Perhaps I should even deprecate the closure memoization feature, since it doesn't seem that useful.

Guillaume

--
You've received this message because you've subscribed to the Gaelyk Google Group.
To send an email to the group, please write to: gae...@googlegroups.com
To unsuscribe from this group: gaelyk+un...@googlegroups.com
To show more options: http://groups.google.fr/group/gaelyk?hl=en

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Twitter: @glaforge

Google+: http://gplus.to/glaforge

[Scott Murphy]

I am very interested in closure memoization as well. That being said,
couldn't something like this be made useful by taking an optional
parameter
for the memcache key?

[Guillaume Laforge]

Yes, it's certainly possible to implement something like that.
I guess if one defines a specific key, it means we don't let the
cached result vanish after 60 seconds, since we want it to be
reusable.

So: no specified key == cached for 60 seconds, a key is specified ==
cached as long as possible.

We can also think of some additional parameters like the duration of the cache.

Don't hesitate to create such tickets if you wish -- or even implement them ;-)

Guillaume

Google+: http://gplus.to/glaforge