[boost] Re: Re: Re: STL applied to disk

From: Bohdan (warever_at_[hidden])
Date: 2002-11-20 02:44:32

"Wesley W. Terpstra" <terpstra_at_[hidden]> wrote in message
news:20021119194815.GB939_at_ito.tu-darmstadt.de...

> My best idea is the map, but I know that this is too slow.
>
> It makes my 40Mb test-case go from under a second to twelve seconds.
> All CPU bound; not disk. That is bad.

Agree. Commonly kind of hash table is used for this. Epecially it would
be effective with keys of primitive types like int double char ...

>
> I have fuzzy ideas about sneaking a pointer into the sector buffer in place
> of the object (till serialize), but the alignment and size problems here
> worry me.

Looks terrible :)

>
> Other things to consider with a cache of objects is that the wrapped
> transaction will need to reserialize and destroy them all on commit, which
> means that keeping the map in the database is not the right place; the
> transaction has to find all of them.

This is not problem at all.
You don't need to destroy them untill commit is retaining.
What you really need is to find objects belonging
only to this transaction i.e. store write-locking transaction
pointer/id inside persistent object. Each time
object is modified
it is added to its transaction context (commonly its transaction
is defined by current transaction == transaction attached to
current thread ).
The other way can be
single cache with locking information. In this
case each cache entry contains information
about read locks and single write lock.
When you need to commit some trx than
you just commit cache etries write locked
by this transaction.

regards,
bohdan