I suggest updating the documentation as well to make it clearer...
On 2010-07-29 21:45, zonkzen wrote:
First of all: thank You Markus for your answer, it really helped me understand what's going on. For all that will have similiar problems/issues/concerns. I've implemented Session-per-Request ( http://using.castleproject.org/display/AR/Enable+Session+per+Request ) and removed all other sessions from my code. I also set this session to be FlushMode.Never. Now I can clearly see that only one Session is created and it indeed has SqlTransaction attached inside. I still have TransactionScope(TransactionMode.Inherits) here and there (save/update/ delete methods) and it plays along really nice! If something fails, then all transactions are rolled back. There's still two questions: 1. Since now I have only one Session, all nHibernate objects are attached to it ( despite the FlushMode.Never, but it's by design ). Question is really not precise and kind of stupid, cause it's hard to measure, but how many objects can be attached to session till I will start feeling it's something that slows app down? Are there any hard numbers or benchmarks I can do? Anything that can help me on that? 2. On page: http://using.castleproject.org/display/AR/Enable+Session+per+Request , there's this sentence: "NOTE: Often ASP.NET will process HTTP requests for items such as images through the Begin/End page lifecycle. This is fixable via changing the configuration, however this technique injects a safe- guard." Can anyone bring some light to it? What did the author meant by that? What's the fix for eliminating session for e.g. image requests? Thanks in advance!
-- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
