On 08/11/2010 15:40, Remy Maucherat wrote: > On Mon, 2010-11-08 at 14:31 +0000, Mark Thomas wrote: >> We might be able to avoid that be limiting the version to just integers. >> I think that is reasonable but would like to hear some feedback from others. >> >> That does raise the issue of whether to convert the provided version to >> a (zero padded) string and continue with String compares or to convert >> the version parsed from the session ID to an int. Performance is the >> thing that worries me but I might be over-thinking this. Some >> micro-benchmarks are probably called for. > > Ah, it seems this bad feature is spawning ugly hacks :( Why is it a good > idea to append one-more-thing to the session id ? Already with the JVM > route it is costly, and has spawned a ton of bugs (updates not being > made when switching to a new node, etc etc). > > Isn't it better to have the mapper simply query the existing managers if > multiple versions exist ? > > The algorithm: > - if the Context has old versions active, the mapper will query the > managers to find the right Context > - of match, then you know the context > - otherwise it belongs to the latest version > - if no old versions of a context, no manager lookups, so no cost
I did consider that approach but rejected it for a couple of reasons: - Mapper needs to be manager aware - it isn't currently - Performance Now the clean-up is in place and we can focus on the actual changes I'll probably go back and take another look at this option. It is almost certain I didn't fully explore all the possible ways of doing this. > I don't agree with adding a version number/id to the session id, or > changing its format, this will create legacy issues, as we can see right > now. An understandable concern. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
