At 08:59 08.11.01 -0800, you wrote:
>My specifics are that I have a need to permanently store tens of thousands
>of smallish (5K) items. I'm currently using a simple file system store,
>one file per record, all in the same directory. Clearly, I need to move
>into a directory tree for better perf
Bill Moseley wrote:
>
> Hi,
>
>
> I'm looking for a little discussion on selecting a data storage method, and
> I'm posting here because Cache::Cache often is discussed here (along with
> Apache::Session). And people here are smart, of course ;).
>
> Basically, I'm trying to understand when t
On Thu, Nov 08, 2001 at 10:54:11AM -0800, Andrew Ho wrote:
> Let me point out that if you are using MD5 hashes for directory spreading
> (i.e. to spread a large number of files across a tree of directories so
> that no one directory is filled with too many files for efficient
> filesystem access),
> Later versions of BerkeleyDB have a row-level lock available which works
> pretty transparently.
That's what I'm talking about. Multiple writers can cause deadlocks unless
you run their deadlock daemon or implement their deadlock handling API
yourself.
> However, this works using mmap() so it
At 10:54 AM 11/08/01 -0800, Andrew Ho wrote:
>For example, say your keys are e-mail addresses and you just want to use
>an MD5 hash to spread your data files over directories so that no one
>directory has too many files in it. Say your original key is
>[EMAIL PROTECTED] (hex encoded MD5 hash of th
Hello,
PH>If you do use BerkeleyDB, I suggest you just use the simple
PH>database-level lock. Otherwise, you have to think about deadlocks and I
PH>found the deadlock daemon that comes with it kind of difficult to use.
Later versions of BerkeleyDB have a row-level lock available which works
pret
Hello,
DC>For example, file system caches fill their directories roughly equally
DC>when their paths are created from MD5 hashed keys. Doing something
DC>simple and unique like "URL-encoding" the key to make a legal identifier
DC>(legal in the sense that it is a valid filename) wouldn't distribut
On Thu, Nov 08, 2001 at 01:11:21PM -0500, Barrie Slaymaker wrote:
> Even a bit more OT: one thing to watch out for, especially if you
> plan on caching a *lot* of data, is that the Cache::* modules did
> not do collision detection on MD5 collisions the last time I looked.
> Forgive me if that's c
On Thu, 2001-11-08 at 10:11, Barrie Slaymaker wrote:
> On Thu, Nov 08, 2001 at 08:59:55AM -0800, Bill Moseley wrote:
> > Hi,
> >
> >
> > I'm looking for a little discussion on selecting a data storage method, and
> > I'm posting here because Cache::Cache often is discussed here (along with
> > A
On Thu, Nov 08, 2001 at 08:59:55AM -0800, Bill Moseley wrote:
> Hi,
>
>
> I'm looking for a little discussion on selecting a data storage method, and
> I'm posting here because Cache::Cache often is discussed here (along with
> Apache::Session). And people here are smart, of course ;).
>
> Bas
> Basically, I'm trying to understand when to use Cache::Cache, vs. Berkeley
> DB, and locking issues. (Perrin, I've been curious why at etoys you used
> Berkeley DB over other caching options, such as Cache::Cache).
Cache::Cache didn't exist at the time. BerkeleyDB seemed easier than
rolling o
Hi,
I'm looking for a little discussion on selecting a data storage method, and
I'm posting here because Cache::Cache often is discussed here (along with
Apache::Session). And people here are smart, of course ;).
Basically, I'm trying to understand when to use Cache::Cache, vs. Berkeley
DB, an
12 matches
Mail list logo
