JPetStore架构的疑问

研究ibatis的JPetStore有一段时间了，公司里也采取
类似的架构做过项目，我觉得是一个非常实用的轻量级
构架，但我觉得似乎有两个问题：
1）service模式，所有的逻辑包装在Service类中，
而Service的实例采用singleton模式获得，不知道
在多用户多并发量的情况下是否适用，比如，一个
较为费时的service的操作，如果一个用户在操作进行
中，另外一个用户同样调用该service实例的该操作，
是不是会阻塞住呢？这里面有多线程机制吗（似乎是
没有提供）。
2）不知道各位有没有用过JPetStore对context的封装
ActionContext类，似乎在多用户同时并发的情况下
sessoin会互相混淆，这个用户会取到其他用户的session.

不知道各位有没有对这两个问题考虑过，我的观点正确否，
有什么办法改进。

1.service模式中如果使用事务机制操作数据库，将会存在性能瓶颈，如果只是读取，则不会。但是我个人不建议使用Singleton模式，现在可以用Ioc模式替代，你可以使用Spring的Pool池拦截器来实现Service的多实例化，这是稳妥的好方式。

2.ActionContext我不喜欢，因为是客户端每次请求都要生成，这在大访问量情况下是非常可怕的。

我个人认为：JPetstore是一个无伸缩性、无性能考量的小网站应用系统，它的架构没有特别之处，吸引人的地方是它的 iBATIS 。

TSS的讨论不错，相信你看过：

http://www.theserverside.com/news/thread.tss?thread_id=14243

>>但是我个人不建议使用Singleton模式，现在可以用Ioc模式替代

Singleton模式的“意图”写着：“用于保证该类型只创建全局唯一的对象。”IoC模式的“意图”写着：“用于在对象之外管理对象之间的依赖关系。”请问“用IoC模式替代Singleton模式”应该如何做？请指教。

>>我个人认为：JPetstore是一个无伸缩性、无性能考量的小网站应用系统，它的架构没有特别之处，吸引人的地方是它的 iBATIS 。

可否请详细介绍一下，JPetstore“无伸缩性、无性能考量”体现在哪里？

JPetStore是个相当简洁的示例，只是它的Service层可扩展性和事务的可管理性不够强，有兴趣的话看看MiniSOA改写的JpetStore http://210.52.149.164:10000/alix/

> 1）service模式，所有的逻辑包装在Service类中，
> 而Service的实例采用singleton模式获得，不知道
> 在多用户多并发量的情况下是否适用，比如，一个
> 较为费时的service的操作，如果一个用户在操作进行
> 中，另外一个用户同样调用该service实例的该操作，
> 是不是会阻塞住呢？这里面有多线程机制吗（似乎是
> 没有提供）。


public class MyClass implements Runnable {
  public void run() {
    while(true) { }
  }
}

这是世界上最费时的操作了吧？它需要的时间是……无穷大。那么下面这段代码会不会阻塞住呢？


for(int i = 0; i < 10; i++) {
  new Thread(new MyClass()).start;
}

稍微动动脑筋就知道答案了。另外，多线程机制需要你来提供吗？那我们还要应用服务器来干什么呢？

> 1.service模式中如果使用事务机制操作数据库，将会存在性?> 瓶颈，如果只是读取，则不会。但是我个人不建议使用Single
> on模式，现在可以用Ioc模式替代，你可以使用Spring的Pool?> 拦截器来实现Service的多实例化，这是稳妥的好方式。
>

我希望banq看看我前面的一个回复。如果business service都是stateless、immutable的POJO，为什么要费力不讨好的去搞什么多实例化？Singleton为什么不好？希望banq能明确解开我这个疑惑。

我用spring 的httpinvoker做分布，在并发情况下sessoin会互相混淆，这个用户会取到其他用户的session,不知道该如何解决这个问题