求问一个代码设计的问题

原本的数据访问层都是静态的，连conn也是静态的，原因是原本的设计是一次只支持一个连接串的，现在因项目需要，要改成同时支持多个连接串的方式，可以认为一个用户就是一个连接串。假如还是使用原本的静态数据访问层则每切换一个用户都要从新设置连接串，由于多个用户又是多线程访问的，于是还要上线程锁lock一下，这无疑还是单线程模式呢。以前没有碰到过这样的问题，讨教一下怎么改才能使整个项目的改动最小呢？有什么好的方法或心得求分享一下，谢谢！

解决方案

“多线程访问的，于是还要上线程锁lock一下”，你可以想象一下一个有着200个收银台的大型购物中心，突然只开一个收银台，顾客会是什么体验。
但是基于你原来的“设计”，进行 lock 又是不得已，否则连基本的数据正确性、不崩溃都无法保证了。假如不放弃原来的，那就只好 lock。
而且即使是原来的设计，本人估计你也没有在“嵌套业务逻辑”等方面使用过它。例如外层循环一个查询要使用“只向前进的数据库光标操作”来读取数据库查询记录，而循环内部调用的n个方法中又要本人有查询，莫非内部查询方法不创建另外的一个数据库会话吗？假如都是一次性查询出来数据放到内存里，那么你的程序不但慢，而且占用内存量可能也比其它程序高10倍。

引用:

Quote: 引用:
连接池你知道是啥吗？

估计改不了用连接池了，这个是以前那些人设计的，现在说要改，做这个需求。

你用到的 .net 中的（你说的 conn）基本上都是自动支持连接池的。你创建一个 conn 时使用的连接字符串就是一种 key，假如连接池中有相同签名的连接字符串，则就不会去创建物理连接，而是直接重复使用上一次用完的 conn。你用 static 方式，反而用不到连接池，原因是你从来不及时归还 conn 实例给连接池。
因此，这里并不是让你本人去研究、编写一个连接池代码（其实有20行代码也就够了），而是让你不要使用 static 方式，它就自动能借助连接池机制来优化了。
本人以为 static 提高了性能，其实那是你没有遇到复杂的情况。连接池机制是从更加实践的开发经验中总结出来的，可以在复杂的根本不可能 static 的情况下也能保证性能，用10个物理连接可能就能自动地应对（一段时间内）数万逻辑连接请求了。