-
1. Re: very slow bdbje loader implementation (CR3)
genman Jul 12, 2007 1:51 PM (in response to srnm)Well, when I wrote the JDBM cache loader I designed it at a finer level of granularity, not understanding that you should really be storing a single object per node.
Locking, replication, eviction all work off of nodes as units of work, not node keys. -
2. Re: very slow bdbje loader implementation (CR3)
srnm Jul 12, 2007 8:50 PM (in response to srnm)Are you saying that the jdbm loader doesn't support the semantics of the cache properly? If so http://jira.jboss.com/jira/browse/JBCACHE-696 would be a negative?
Am I correct in thinking that the FQN is really the "key" and that the fanout of actual keys underneath should be kept very small?
Do the jdbc loaders update a row/single key in a node at a time? If so, how do they support the semantics of the cache?
Are there any hints recorded as to how to design a cache structure for optimal performance?
Lots of questions, apologies... -
3. Re: very slow bdbje loader implementation (CR3)
manik Jul 16, 2007 8:27 AM (in response to srnm)"srnm" wrote:
Am I correct in thinking that the FQN is really the "key" and that the fanout of actual keys underneath should be kept very small?
Correct. This will help you achieve maximum concurrency in the cache."srnm" wrote:
Do the jdbc loaders update a row/single key in a node at a time? If so, how do they support the semantics of the cache?
By using a separate shared lock on the Fqn. See, for example, line 181 in JDBCCacheLoader"srnm" wrote:
Are there any hints recorded as to how to design a cache structure for optimal performance?
It depends. Where are your bottlenecks? Is it in concurrency, replication or cache loading? :-) Either way though, use the tree structure fully, don't put too much in each node.