It's ReadCommitted --- you can only read committed rows, but when they
are changed, you have to wait until the transaction commits.

The problem with SessionScopes is that each SessionScope starts its
own ISession and ITransaction. If you nest SessionScopes, you nest
sessions.

Generelly, session management is an infrastructure concern, not a
business concern. With a web app, you can use session per request: Use
a simple SessionScope that spans the whole request, set it to flush
explicitly and call SessionScope.Current.Flush() from within your BL
methods to write changes to the database.

You don't have to use transaction scopes with your behaviour,
SessionScope uses an implicit transaction that is committed on the end
of the scope unless an exception was caught, in which case the session
is rolled back.

-Markus

2010/7/27 zonkzen <[email protected]>:
> Hi !
> This question is purely AR related.
>
> Let's say I have 2 layers in my web/wcf application - DataLayer and
> BusinessLayer.
> DataLayer contains almost atomic operations that work on mappings
> (find, get, save, special find, cross find , etc. :) ). There is a lot
> of HQL or Criterias. There's no SessionScopes used in this layer. Some
> of my mappings contain lazy collections.
>
> Now, the BL layer has methods that contain business logic included
> mixed with DL calls - that's normal. For each public method that have
> readonly operations inside I have SessionScope(FlushAction.Never)
> specified. For all those methods that have some Save or Update
> operations, I'm using TransactionScope(), with try catch inside,  with
> direct VoteCommit at the end of the method and VoteRollback inside
> catch clause. I have ReadCommitted set as isolationLevel.
>
> For basic situations this works. I started to have real problems when
> I wrote methods that uses other methods with their own transactions
> inside - I'm talking about locks. For example I have method with
> transaction that is recursive.
> It seems that some 'read' methods (that have their own
> SessionScope(FlushAction.Never)) are blocked because of other
> transactions.
>
> I can't really track down what exactly is wrong, but I'm starting to
> think that I have some major design problem.
>
> Help on castle site doesn't do much for me, also tests in AR sources -
> they are simply too basic for me.
>
> Can anyone really explain how should I use the TransactionScopes or
> what's my mistake?
>
> --
> 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.
>
>

-- 
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.

Reply via email to