Small keys, large objects, lots of data and lots of memory are the case for
offheap. Not so easy.
Ciao,
R
Il giorno 07/nov/2012 17:38, "Johannes.Lichtenberger" <
[email protected]> ha scritto:
> On 11/07/2012 05:04 PM, Raffaele P. Guidi wrote:
>
>> I understand your frustration, I have some smaller OSS projects out there
>> that didn't catch any attention at all. Probably focusing on more specific
>> subjects or just contributing to existing projects could be a way to get
>> some satisfaction.
>>
>
> Yes, but from time to time, I'm able to merge or rather insert changes
> manually from the forked project, that's probably the best satisfaction
> right now. For instance iSCSI support seems to be on the way. And I think
> compared to some approaches our system is really cool, so hm, maybe
> sometime anyone recognizes it. For instance it borrows some ideas from
> ZFS/BtrFS. Anyway, running unit tests for new features sometimes are a
> satisfaction, too ;-)
>
> Regarding my issue, it might sound strange, but I really don't know in
> which situations it's better to use a non-heap cache. Do you think it makes
> sense for a transaction-log? And/or for reading and caching data from disk?
> The transaction-log for the first version usually is very large, as it's
> most commonly the import of XML-documents. I think later changes in
> comparison are rather small (furthermore only deltas, that is changes to
> either the last full version (differential changes) or incremental changes
> (simply the changes from the current transaction) until the next full
> version of changed "pages" is written. If that helps to determine if it
> makes sense to use direct memory (different caches for reading and the
> write transaction-log). Do you as of now have any documentation besides
> Javadoc?
>
> thank you & kind regards,
> Johannes
>
