I can definitely see keeping btree node allocations to their own page pool. It would make sense to introduce a container concept for allocations. A btree is a natural case where you (a) want the nodes allocated together; and (b) you don’t want other records allocated with the btree nodes. Hash tables would be another. However the same concept could be reused for application collections.
[mailto:firstname.lastname@example.org] On Behalf Of Kevin Day
Sent: Tuesday, April 11, 2006 12:49 PM
To: JDBM Developer listserv
Subject: re: [Jdbm-developer] primary and secondary indexes in the record manager
Yes - I've looked at the GOM implementation (and have worked extensively with similar approaches - Microsoft COM, mozilla cross platform COM, etc...). I can see the utility in some situations, but for the development I do, losing the runtime type checking would be a massive problem. I'm trying to think of jdbm as a true object database, and not just a way of storing key/value pairs. Certainly, I could create wrapper classes that call the GOM framework, then work in an object oriented manner, but that is a heck of a lot of work (and boring work at that).
As a user of an oodbm, I expect to be able to work with objects the way I normally work with objects, but have the persistent capabilities. The solution I'm going for is much closer to JDO than COM... So, the idea of using events and listeners is fine - but we have to have a true object oriented mechanism for driving those events. Short of code injection, aspect weaving, or some ugly notification requirement imposed by the API, I just don't see how to achieve this. The alternative, then, is to provide some sort of reverse lookup method that either caches index info for all retrieved records or provides some sort of view into the index keys (or node locations) for each recid.
Expanding on my comment re: blink trees: We could certainly store the index pages on DATA pages, if desired - but there may be advantages (locality again!) to storing the index pages in their own page thread. Given that index page objects are likely to change much, much more frequently than data pages, it may make sense from a caching and free page perspective to keep them in a separate page thread.
Likewise, in my proof of concept, I could have stored the version tables on DATA pages, but I chose not to because version tables are extremely short lived, and will undergo a lot of churn. If the version tables were interspersed with the data, we'd wind up with a huge amount of fragmentation. I think (but can not say with absolute certainty) that maintaining these data structures in a separate page thread should optimize caching behavior, allocation, etc...
------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbmemail@example.com https://lists.sourceforge.net/lists/listinfo/jdbm-developer