At 12:01 PM 6/5/2002 -0700, you wrote: > >>>>> "Peter" == Peter Donald <[EMAIL PROTECTED]> writes: > > Peter> ie Consider the following example. When connecting to a > Peter> database and you need to retrieve resources to access > Peter> database from a service directory (whether that be > Peter> ServiceManager, ComponentManager or JNDI Context > Peter> etc).Should you > > Peter> a) Store the Connection object in service directory b) > Peter> Store a DataSource in service directory > > Peter> Obviously most people are going to say (b) because it > Peter> scales well and is simple to do. > >Somehow I feel DataSource is similar to Request that Berin proposes.
I don't think so - Request still makes resource management part of directory service which is just plain wrong in my mind ;) >Apparently you don't like the idea of embedding such mechanism into >ComponentManager itself for it may foster sloppier design. I think it is sloppy design in itself ;) But then again - me and Berin have been arguing over this for about 2 years so I don't think either of is going to change our minds right away though I think I have a better case now than I did back when it started ;) > Peter> and repeat for all performance sensitive operations. It > Peter> would make cocoon sooo much faster and it would also mean > Peter> we wouldn't have to keep making compromises in core parts > Peter> of Avalon for what I consider to be bad use cases. > >I feel that profiling is in order to determine the performance impact >of switching to Request architecture. > >Yesterday I realized that String hashing and comparisons (not >construction though) may be of little relevance to performance. Don't >you think synchronization to be a bigger performance drain? depends on so many factors it is hard to say. Certain JVMs (suns not hotspot) suck badly at synchronization while others suck at garbage collection etc. The best way to do it is fire up JProfiler and have a look at how much GC is occuring vs CPU time (I don't know of any profilers that measure monitor contention though). > I still think the change would be a boon if it reduces code as Berin >demonstrated. It would double the size of all my component accesses so I tend to not think of it as good in that way ;) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
