"Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
