But cache.ram is theoretically faster than cache.disk.
Besides, what is the pros and cons of using urllib.urlopen('http://
localhost:8000/myapp/...').read() to visit an action? My draft:
Pros:
- There is no need to app's environment for the cron job to run, hence
avoids potential locking problems radically.
- Just a urlopen(...).open() is considered less overhead than a full
"web2py -P -N -S ..."
Cons:
- I did not find a way to auto detect which port the main web2py
process is running at.
On Jul 28, 6:06pm, Massimo Di Pierro <[email protected]> wrote:
> The solution is cache.disk
>
> > PS: Using cache.disk() is not (yet) a workaround for
> web2py_win.zip. I
> > report a bug about that in another post.
>
> I do not recall this. Can you tell us more and point to the post?
>
> Massimo
>
> On Jul 28, 2010, at 4:48 AM, Iceberg wrote:
>
>
>
> > Scenario: In one of my small enterprise app, my action is time
> > consuming, so I use cache. Furthermore, I setup a cron job to "touch"
> > this action frequently, hoping that other real users will be benefited
> > by always have cache hits. Example as below.
>
> > @cache(request.env.path_info,time_expire=1800,cache_model=cache.ram)
> > def index():
> > result = do_a_time_consuming_job()
> > return {'result': result}
>
> > # the crontab file
> > */30 * * * * root **default/index
>
> > Nice plan, huh? But it has no effect. Because each time the cronjob is
> > seemingly invoked in a separated process space (via "web2py -P -N -M -
> > S myapp/default/index -a <recycled>"), so the main process's cache.ram
> > is not touched.
>
> > So, is it possible to change the implementation, let the "visit my
> > action" cronjob be done by this way?
> > urllib.urlopen('http://localhost:8000/myapp/default/index').read()
>
> > By the way, my current workaround is to write my crontab file like
> > this:
> > */30 * * * * root
> > **applications/myapp/cron/trigger.py
> > and my trigger.py is based on urlopen(...).read() mentioned above.
> > The workaround works, but I don't like the fact that it hardcode the
> > app name (as well as the port).
>
> > PS: Using cache.disk() is not (yet) a workaround for web2py_win.zip. I
> > report a bug about that in another post.
>
> > So, what's your opinion?
>
> > Regards,
> > Iceberg
>
> > --
> > mail from:GoogleGroups "web2py-developers" mailing list
> > make speech: [email protected]
> > unsubscribe: [email protected]
> > details :http://groups.google.com/group/web2py-developers
> > the project:http://code.google.com/p/web2py/
> > official :http://www.web2py.com/
