有真正理解Tapestry中 persist 对象含义的么

在 server-side state 一章中，Tapestry的作者重点讲了persist的含义，说他的作用很大啊，解决了许多其他框架的变量状态问题，但是看了他的解释，不是很理解：

他能自动管理persist对象的状态，那麽到底是存在 session中还是 application中呢，这个 Object pool中的对象什么时候被释放，什么时候有效呢，对多少个线程有效？理解这段话的朋友请指点！

1.persistent对象每个线程都不一样，也就是说每个线程都拥有一个persist对象；
2.persistent对象能保持有状态类型，也就是说在一个请求处理中，persisitent对象保持不变。
3.Tapestry的pool池的释放，有待高手解答。

你是这样理解的，但是
1.“persistent对象每个线程都不一样”有什麽好处，有这样的应用场景么，可以举个例子？这样对于开发者来说或者对于用户来所有什麽特别的么
2.在一个请求中，也就是一个request中，其中的变量当然不变了，比如说 request.setAttribute 其中一个变量，你如果不修改它，当然不变，这和persistent没关系吧
3.这个 page pool他解释的含糊不清，什麽情况下使用，比存在 session中有什麽好处，他的lifecycle，都没有说明白



transient state 状态储存在 request中，而又状态的变量储存在 session中，我没有觉得有什麽不方便和麻烦的，session这样处理很好，他为什莫说 awkward 和限制开发者编程呢？

tapestry用起来简单，理解起来却要费时的多，很多东西必须要深入它的源代码才能理解。4.0较3.0变化很多，建议多看看源代码。若对hivemind不想深入，只需理解它的配置方式即可，t4的配置方式大部分都基于hivemind，只要你掌握了服务注入方式，基本上t4的应用你便可灵活应用了。过一段时间我会以项目实际实践的角度写一个3.0到4.0的升级指南，或许读初学者们有点帮助。

我的几个问题对理解 Tapestry很有帮助，特别对于他处理变量的方式，很重要，Tapestry是很好的基于事件的框架（不知道和JSF比起来哪个更有优势），所以值得花些时间去理解他
我那几个问题谁能回答一下？

1.Servlets, and by extension, JavaServer Pages, are inherently stateless. That is, they will be used simultaneously by many threads and clients. Because of this, they must not store (in instance variables) any properties or values that are specific to any single client.
一般的jsp和servlets没有状态，它们被很多线程和客户端使用，所以它们不能为任何一个客户端保存任何属性值 。
2.This creates a frustration for developers, because ordinary programming techniques must be avoided. Instead, client-specific state and data must be stored in the HttpSession or as HttpServletRequest attributes. This is an awkward and limiting way to handle both transient state (state that is only needed during the actual processing of the request) and persistent state (state that should be available during the processing of this and subsequent requests).
这些会增加开发者的困难，原来的技术不能用了。客户端的状态和数据必须保存在httpsession或作为httpservletrequest的属性，这是笨拙的，对transient状态（仅在请求的实际处理中需要保持的状态）和prsistent状态（在请求和子请求处理过程中都有用的状态）是无法区别处理的。
3.Tapestry bypasses most of these issues by not sharing objects between threads and clients. Tapestry uses an object pool to store constructed page instances. As a page is needed, it is removed from the page pool. If there are no available pages in the pool, a fresh page instance is constructed.

tapestry的解决方案是不在线程和客户端共享这些对象。tapestry使用object pool（自定义对象池）来存储已创建页面的instance（实例？）。当页面需要时候，页面从页面池中取出。也池中没有可用页面时，fresh页面实例被创建。
4.For the duration of a request, a page and all components within the page are reserved to the single request. There is no chance of conflicts because only the single thread processing the request will have access to the page. At the end of the request cycle, the page is reset back to a pristine state and returned to the shared pool, ready for reuse by the same client, or by a different client.

In fact, even in a high-volume Tapestry application, there will rarely be more than a few instances of any particular page in the page pool.
在一个请求处理过程舟骨拿，页面和页面上的组件被被单个请求所保留。这样就会没有冲突的机会因为只有单线程处理访问指定页面的请求。在请求循环的结束中，页面会重新返回到pristine状态（持久状态？即对象的原先状态）并返回到对象共享池中，准备为同一个客户端，或另一个客户端（注意另一个客户端有自己的页面和页面组件）重新使用。实际上，即使在大业务量的tapestry程序，页面池中任何详细的页面实例没有几个。
5.For this scheme to work it is important that, at the end of the request cycle, the page be returned to its pristine state. The prisitine state is equivalent to a freshly created instance of the page. In other words, any properties of the page that changed during the processing of the request must be returned to their initial values.

The page is then returned to the page pool, where it will wait to be used in a future request. That request may be for the same end user, or for another user entirely.
安排这样处理的重点是，在请求循环的末端(快结束时)，页面会恢复到pristine状态。prisitine状态等同与新创建页面实例的时候。换句话说，任何页面在处理过程中改变的属性必须回到初始值。页面返回到页面池中，会等待在下一个请求中被使用。这个请求可能来自同一个终端用户，或其它用户。

我想上面已经说明了tapestry和jsp处理的区别。