[Design of POJO Server] - Re: metadata simplication
by wolfc
We're still mixing merging and parsing logic, which to me looks like an unsolvable puzzle.
What's the function of the override (NamedMetaDataWithDescriptionGroupWithOverride.data)?
Either it's for holding data from the jboss xml parse or it's for referring to the override. IMHO it can't be both.
The code now creates a StackOverflow in JBossEnterpriseBean.setDescriptionGroup. (ensureOverride returns a new instance of the same class and calls setDescriptionGroup.)
I have changed this part, but as long as the above question is unanswered the solution is by definition wrong.
Another thing is the merge method: the current use of the merge is contradicting the implementation.
MergeUtil.merge:
JBossMetaData merged = new JBossMetaData();
| merged.merge(jboss, spec);
| merged.setOverridenMetaData(spec);
| return merged;
vs for example IdMetaDataImpl:
public void merge(IdMetaDataImpl merged, IdMetaDataImpl original)
| {
| ...
| if (id != null)
| merged.setId(id);
| else if (original.id != null)
| merged.setId(original.id);
| }
where merged is the target. I would rather see this as target (as in MergeUtil) and have the following signature:
interface Mergable<M>
| void merge(M original, M override);
Or maybe only a one-way merge:
interface Mergable<M>
| void merge(M override);
Because the default (non-performant) code is always:
void merge(M original, M override)
| {
| merge(original);
| merge(override);
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097391#4097391
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097391
18 years, 5 months
[Design of JBossCache] - Re: JBCACHE-1153 - structural nodes
by mircea.markus
anonymous wrote : I think this can become a problem since even a node with no data still has an overhead and an impact on memory. I think they should still be considered for eviction.at the time the
If we consider for eviction such a node, and it gets to be evicted, nothing really happens at that point, unless it is a leaf node. For all non-leafs nodes, the eviction would only empty the attribute map, which in our case is already empty (effect of eviction would be void). I also agree that those nodes are not empty and somehow makes sense counting them as nodes to be evicted, but on the other hand they reduce the benefits of it which is cleaning up memory and allow for other data to be kept there...
anonymous wrote : Can't we just use the resident flag for this purpose instead?
| we can go on and implement based on this approach. The implementation is a bit trickier due to transactions:
| cache.put("/a/b/c","k","v");
| //at this point "/a" and "/a/b" are structural + resident
| tx.start()
| cache.put("/a/b","k2","v2"); //at this point "/a/b" becomes not-structural
| tx.rollback();
| //"/a/b" should not be structural + resident as transaction failed
|
anonymous wrote : See my comment on http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097183#4097183 about tombstones and invalid nodes. It shows how you could have empty nodes with no data, that *should* be considered for eviction.
I haven't totally get it (Mon morning :) ), let's have a chat
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097378#4097378
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4097378
18 years, 5 months