|This is a good test because it shows worst case, but can it be called a
|realistic test? I'm only bringing this up because, well, if I saw
|somebody with an application designed such that every user had to share
|a single synchronized object, I'd say "well, yah, that'll perform fer
|shite!"
you don't get it, I don't want something realistic I want a COMPLETELY
SYNTHETIC test banging on the cache so I can see where it leaks and breaks.
You know how early planes were tested for air tightness? they are put under
water with pressured cabins and they look for bubbles in the pool.
Was that realistic ? hell no! was that useful? hell yes!
|> anybody ELSE seen this? I am almost leaning towards TOTALLY removing the
|> passivating caches and associated mutex logic as is
|
|
|It does look like the behavior people have been complaining about. I'd
|not be in favor of permanently removing the passivating caches, however
well frankly part of the test is making sure that I see EXACTLY what doesn't
work. We have a lot of noise but nothing concrete no repro case that I can
work with.
|- making them non-default, sure, rewrite them absolutely, but they
|really have to be available for truly large installations. Truly large
|installations (running over N terabyte databases) will still need memory
|management. No that's not a typical installation, but don't you want to
|be able to support it?
yes...
marcf
|
|
|>
|> Ok I will say the word... this is shite ...
|>
|> or is it just me?
|>
|> marcf
|>
|> _________________
|> Marc Fleury, Ph.D
|> [EMAIL PROTECTED]
|> _________________
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
