> > So - we need more lightweight and simple TempCacheManager. Ideally
> >it can be inherited from abstract base CacheManager class
> >...
> >
> >
> This is just wrong. Think about it some more. Hint: the major changes
> aren't to the cache manager. Even better, do some research.

Probably i was misunderstood. I didn't speak that TempCacheManager is all
of we need. I didn't say that cache manager is major changes. I just say that
current CCH don't satisfy the needs of temporary page management. So we need
a new _additional_ lightweight cache manager exclusively for temporary pages.

> > Option a) needs no data page management, it simple create new file for

temp

> >table data and more files for its indeces. All other options require to track
> >empty
> >pages list and to provide above allocation policy.
> >
> >
> >
> There already is a space management policy implemented. You don't have
> to invent another. (This is called "leveraging code").

Idea is to isolate records from different table instance on defferent pages.
It will allow instant cleaning up from that table instance after use.

Current allocation policy allow to allocate on the same page data rows from
temp table instances of attachment 1 and attachment 2 (or tx1 and tx2 in case
of ON COMMIT DELETE)

> Let me give you another hint: Use objects. Think about internal
> layering. When you find the right answer, it will be obvious.

I'll try ;-)

Regards,
Vlad

PS Sorry, i'm wrongly press 'Reply-to-sender' at first time