关于会话的一些应用

在软件的系统设计中涉及到了各种会话，权限会话、事务会话、连接会话、http请求会话等等，所谓会话就是用来保证在多任务或多线程执行环境下，保持数据一致性的用户上下文。

很多时候我们可以利用线程栈的隔离性做会话处理，比如在处理一些事务的场合，但是在一些高并发场合的连接会话处理上，就没法利用线程栈的隔离性作为会话上下文，因为可能在一个线程栈上维持了多个连接，这几个连接在异步端口上做的调用。

作为连接层会话，高性能的并发连接都是利用异步端口的复用，因为有很多的TCP连接，并且每一个连接上的数据也不一定会在一次接收时完毕，此时单靠一次连接上的数据，做数据处理，显然就不行了，我们需要构建一个连接会话，这样在该会话下的所有数据，就知道了都属于同一个连接发来的数据。

构建了完整的连接会话，就可以在应用层高枕无忧了吗，显然也还是不行，因为总会有新的需求，比如，为了提高系统的执行效率，我们需要发起多个并发连接，来接收同一个数据源，比如多线程下载或P2p下载，因为多个线程，在数据源上做切割，首先要做的就是搞定数据源的偏移量，但是怎样能清楚的知道不同连接来的数据，是为某一个相同的数据源服务，还有就是网络断开后，重传怎样重新通过线程分配调度，这都需要一个上下文来协调，这就涉及到了应用会话上下文，但是这种上下文，一般在面向企业级的开发应用中，使用的很少。原因在于这是一个复杂的并行编程，并行编程太复杂了，作为并行编程需要协调的东西，必须在其应用上下文之间，不停的通知，因为这样能及时处理一些异常的死链接等，重新开辟新的连接等，这相当于在应用层面构建了很多小的服务处理容器，这是绝大多数的软件开发人员所驾驭不了的，因为这需要相当好的架构，否则就是一个灾难。

不同的应用场合需要不同的会话，同一概念的会话，也有不同的应用场景，这个需要根据业务的偏向所决定，本质上架构还是面向业务而架构，当业务场景变掉了，可能原来的架构就不适应了，因为不同的架构所偏重的场合不同。一个多线程下载软件和一个实时控制软件的架构，都是面向多线程的架构，但是多线程下载软件的架构，需要考虑的是会话的连贯性，在时间维度上可以持续很长时间，但是所有的应用会话不能变，而实时控制软件的架构，需要的是连接会话的及时性，当会话超时之后，需要立即给出应答，否则控制逻辑，将产生严重的时序不可控性，这会导致连接放在线程栈上的处理将不同。