'TTL' parameter

[gf]

Hello.
Why does it ignore TTL parameter? It's very important feature. For
example, I want to store authorization sessions in MDB, so I need to
purge the storage to prevent storing unneccesary expired items.
In fact, I can set up queue for purging purposes, however it's dirty
solution.
MDB should has the same behavior with memcached: to store TTL in
item's properties and check it before getting. But it should delete
(physically) expired items every hour (for example).

[Clint Byrum]

Unfortunately, its just not that easy.

With memcached, there's no "process" to delete expired items. When you
run out of room in an allocated slab, it then looks in the slab for
expired items that it can get rid of. To make the TTL effective, if
someone requests a key, it won't serve it if it is expired.

With memecacheDB, however, the data is all in a BerkeleyDB database,
so there's no allocation process inside which we can do the expiration.

If you need expiration, you're better off using your queue, or
memcached.

[gf]

I know how memcached is acting. I know how memcacheDB is acting.
memcacheDB should check TTL in 'get'.
memcacheDB should run thread for garbage collector.

[Shaojie Liu]

gf, to enable the functionality of "TTL", you can definitely make this happen in your MCDB interface code, a little complicated but easy and clean, even more flexible i guess.

i agree it's a good consideration for MCDB to provide a tool for "garbage collection",  which can make its data maintanence be handy and transparent to Operation engineers.

my 2 cents.

2009/6/15 gf <kak.serpom...@gmail.com>

[gf pro]

To store expire time in value? It's impossible binary data (e.g. image). How to remove expired items has not been requested?

15 июня 2009 г. 11:29 пользователь Shaojie Liu <liuso...@gmail.com> написал:

[Robert Powell]

memcacheDB was designed for persistent storage so implementing a TTL would defeat the purpose of the project. The feature has been requested multiple times and rejected multiple times as implimenting it would introduce use cases that would need to be supported in future releases potentially leading to the demise of the project. As Clint previously stated:

"If you need expiration, you're better off using your queue, or  memcached".

I would lean towards memcached as it is fast, reliable and uses the same protocol but if you are strangled for memmory or the item must live in the cache until it expires many other caching projects will likely fit your requirements. FYI, it is possible to store metadata in an image however the work of checking it may or may not defeat the purpose of the cache. -Robert Powell --- On Mon, 6/15/09, gf pro <kak.serpom...@gmail.com> wrote:

[Jason DiCioccio]

Of course it's possible.  You'd make your value something like:

struct mdb_value {
  time_t expire_time;
  void *image;
};

2009/6/15 gf pro <kak.serpom...@gmail.com>

[gf pro]

Imho, you all are wrong. memcached is CACHE system in memory (not HDD) with high risk of unexpected damage to data, for example - hard reboot. So I can't use memcached for my data. How to delete old items? It's neccesary to put the keys list to another place and check it periodically?
Damn it. MDB looks like school initiative... I'm using MySQL InnoDB and it hasn't these stupid troubles...

2009/6/16 Robert Powell <dotcoms...@yahoo.com>

[Clint Byrum]

You can enumerate keys quite easily with the 'rget' command.

Maybe you should think about reading the documentation before insulting the project.

[Robert Powell]

You should also read replies to your questions before insulting too. The caveats of storing in memcache were pointed out in the sentence "if you are strangled for memmory or the item must live in the cache until it expires". Some peoples children... -Robert --- On Mon, 6/15/09, Clint Byrum <cl...@adicio.com> wrote: