Hi, I notice every access method is synchronized. This precludes multiple readers in parallel that could possibly mask I/O latency. Is there a reason not to use read/write locks ? If the cache is the problem (multiple cache faults for the same key), one can acquire locks for single cache elements.
A second question: do I understand correctly that there can only be one active transaction ?
Not that I regard it as a problem ...
You're right. At this time, JDBM hasn't been optimized to support multiple reader-single writer access. It shouldn't be such a difficult task to enhance JDBM to allow for this. I'll add it to the TODO list but you're most welcome to submit patches to fix this! :)
To answer your second question, yes, JDBM only supports one active transaction. However, some toolkits which make use of JDBM (ie. the Exolab core classes) allow multiple transactions to happen currently at a higher level and synchronize so that only one transaction commits at a time within JDBM.
Thanks, that was just for my understanding. I'll see if we can submit our cache code that allows more concurrency.
One more thing: I checked the transaction code and it seems that the redo log of the current transactions is completely kept in memory before being written to the log. Have you had problems with large transactions ? How much data is typically touched if you do some modifications to a tree ? I'll try myself, too.
Again, you are right. The transaction log is held in memory until commit. I haven't measured exactly how much memory this requires for modifications in a B+Tree. I wouldn't be too concerned for transactions involving less than 1,000 operations (to give an order of magniture). But, in the end, it depends on the node span, depth of the tree and the size of your keys (non-leaf nodes' size are affectected by the size of the keys).
Log in to post a comment.