Am 30.06.2006 um 00:43 schrieb Vlad Seryakov:
I am not going to argue, it is just old ns_cache used to have all
functionality and was very popular and useful. Now we have more
limited
ns_cache_XXX family and standalone ns_cache does not work anymore.
I do not see who benefits from all this.
Am Freitag, 30. Juni 2006 00:43 schrieb Vlad Seryakov:
> I am not going to argue, it is just old ns_cache used to have all
> functionality and was very popular and useful. Now we have more limited
> ns_cache_XXX family and standalone ns_cache does not work anymore.
> I do not see who benefits from
I am not going to argue, it is just old ns_cache used to have all
functionality and was very popular and useful. Now we have more limited
ns_cache_XXX family and standalone ns_cache does not work anymore.
I do not see who benefits from all this.
Zoran Vasiljevic wrote:
Am 29.06.2006 um 22:44 s
Am 29.06.2006 um 22:44 schrieb Vlad Seryakov:
So, i am being told all the time that i do not use the ns_cache in
right
way, then somebody can define what is the correct and the only
right way
of using ns_cache facility in the server environment? I could be
lost or
un-educated enough but i
I believe Stephen is trying to say that if you use cache module
to save values between two tasks executed by two serialized
thredas, this is kind of unusual "usage".
I always thought that shared memory usage is usual as long as i am using
public API. Limiting API in functionality will lead to
Am 27.06.2006 um 18:52 schrieb Stephen Deasey:
OK. Just checking.
According to our customer, the increase from 3 to 60 secs
did the trick. Now we get no timeouts any more. So, the fix
I did was OK and the default timeout should be increased
If somebody asks me.
But as Stephen says, the ti
Am 29.06.2006 um 19:21 schrieb Vlad Seryakov:
Communication between serialized threads doesn't sound like a
cache to me.
Anyway, the idea is that if you need to do weird stuff it should be
possible, and an ns_cache_info equivalent can be writen in ~3
lines of
Tcl.
Very sad.
I'd sugges
Communication between serialized threads doesn't sound like a cache to me.
Anyway, the idea is that if you need to do weird stuff it should be
possible, and an ns_cache_info equivalent can be writen in ~3 lines of
Tcl.
Very sad.
I'd suggest we define what is weird and what is not first.
--
Vl
On 6/25/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>
> If you need to test for existence, you're doing something wrong.
> Between the test and the action taken depending on the result, the
> result could have changed.
>
> However:
>
>ns_cache_eval $cache $key {error "no entry available"}
>
