Hi Oleg, > Mike put a lot of hard work into the multithreaded connection manager. > To this point it still constitutes the most significant and complex > contribution to the project. Even though it does look like some kind of > black magic MTHCM has been working really well for us. I urge you to not > start taking it apart until we have enough test coverage to test for > regressions. Let's just get it working with the new API and then see > what could be improved.
I appreciate the work that Mike and others have put into the MTHCM. And I can well imagine how it developed over time. I'm sure that originally connections were handed out directly, which explains why they get deleted and created instead of being managed. Then the wrappers came, and so on. But I'm currently looking at the result of all these changes over time. And I can't see where to start with making _small_ changes. I can't "just make it work with the new API". I thought it couldn't be so hard to have one interface for the connections being managed and another one for the wrappers being given to the caller. Then I look at the code and realize that the connections are not being managed by reference, they are subclassed. And the only purpose of the subclass is to create a weak reference to the object itself, which will then be put into some static map, to be retrieved I don't know when for I don't know what. Oh, and there is code to put references in and out of those maps for reasons I don't understand either. The idea of moving some of the classes out to make things simpler was a dead end too. The stuff is nested, with most of the complexity being in the ConnectionPool class with plenty of private methods. It won't help to move it to an extra file and make the methods public. Basically nothing in MTHCM works in a way that is remotely in line with my understanding of what the class is supposed to do. I don't work or think that way. To me, a pool is a finite set of elements, some of which are allocated and some of which are not. You keep references to those elements and when the pool is shut down, you shut down the elements. The manager *knows* which elements it is managing. Weak references and garbage collection??? I'm sorry, but I have serious issues with this code. I'm not just feeling a bit uncomfortable about it, and it's not "I would have implemented this differently" either. It's not the formatting and not the variable or method names. The class is based on an extremely complex design which is completely alien to me. I believe that much of the complexity will simply vanish if a more straightforward design is applied to the problem. I'll give the code one more try tomorrow. But only one. Meanwhile, I'll appreciate any background information on the current design that somebody can give me. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
