Ayende @ Rahien

Bunter commented on Refactoring toward frictionless & odorless code: What about transactions?

Thu, 05 May 2011 18:31:46 GMT

As we have only single inheritance in C# and composition can be rather tricky with different base controllers, alternative approach to the "SessionController" would be to go with storing ISession in controllers (well, global) HttpContext and have an controller extension method to get the session from there.

Thanigainathan commented on Refactoring toward frictionless & odorless code: What about transactions?

Thu, 14 Apr 2011 15:56:56 GMT

Hi, How will this work among the Web Farms ? Will one transaction be available in another farm ? Thanks

José F. Romaniello commented on Refactoring toward frictionless & odorless code: What about transactions?

Wed, 13 Apr 2011 11:51:15 GMT

As some guys mentioned here (my article). Instead of using an attribute to explcitly say where the transaction begin and end, i prefer delay the two things (OpenSession/BeginTransaction) to the first usage GetCurrentSession... and in the End of the request, if there is a transaction commit and/or close the session. NHibernate need transaction for everything, so maintaining an attribute in the request that i will need to use the persistence is something that doesn't worth. I don't want to think how you test all this.

Alex Simkin commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 16:23:48 GMT

@Eber, I am with you on using session per request. This way child actions can sometimes benefit from using cached data.

Marco commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 16:19:54 GMT

This is exactly my transaction boundary starts at the app service layer. My read layer does have this complexity and my command handler begins/commits my transactions. I'm sure we all can think of some edge cases, but so far, no issues when building app layer from use cases.

Eber Irigoyen commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 15:55:57 GMT

What are your reasons to be "strongly against having automatic transactions that wrap the entire request", I'm interested in this, since I've seen some NHibernate experts suggest you do wrap them

Leonardo commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 15:07:38 GMT

@Alex Yes, that's what I was talking about. Nice implementation using ICurrentSessionContext.

Alex Simkin commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 14:44:02 GMT

@Leonardo Then you may want to look at this: [nhforge.org/.../...on-management-for-web-apps.aspx](http://nhforge.org/blogs/nhibernate/archive/2011/03/03/effective-nhibernate-session-management-for-web-apps.aspx)

Leonardo commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 14:31:06 GMT

@Alex But why would you need to specify to not use transaction if you don't access the db? That's like saying things twice. If the session is not used anytime during the action, then that means you don't access the db and therefore you don't need a transaction. And still I think that approach can lead to use the session outside a transaction if the attribute is not updated when the action is.

Alex Simkin commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 14:17:22 GMT

I meant "then you only apply transaction opt-in attribute to those accessing db"

Alex Simkin commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 14:16:21 GMT

@Leonardo 1. If you have most Actions accessing db, then you make opt-in attribute global and apply opt-out as optimization technique (that can be postponed until you start optimization phase) 2. If you have most Actions not accessing db, then you only apply transaction opt-in attribute to them. And, as usual, you cannot have it both ways

joe commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 14:13:07 GMT

If that commit() fails, do you still need to rollback()? Or, is that handled implicitly?

Leonardo commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 14:07:26 GMT

@Alex That would bring the problem of explicitly having to say that you don't want a transaction, and you have to remember to put that on every action that does not access to the db. Also, if you already have an action with that attribute and then you find out that it indeed needs db access (and you forget to remove the attribute), you will be accessing the session outside a transaction, which is not the correct usage.

Bogdan Marian commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:53:42 GMT

@Scooletz If the TransactionScope is sotred inside the HttpContext.Current, the action and all its children will share it. Each of them will call the Complete method to notify the transaction manager that their work is OK to be comitted. There is only one TransactionScope, so only one real transaction shared by all actions.

Alex Simkin commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:43:34 GMT

@Leonardo, @Ayende You can create Transaction Opt Out Attribute and inspect it through ActionExecutingContext in the filter above.

Leonardo commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:41:16 GMT

@Ayende But if you make the Session property lazy, so that it opens when first issued (and opens a transaction also), you have a solution applicable to all cases. @NC I agree with your point, you're right that those are 2 separate things. It's just from the performance perspective where you could perhaps gain something. I'm thinking of a view that has several sections and each could be rendered by a separate action, retrieving different data. For example this blog page. Main view for the post, then a placeholder for the comments, which would be a child action, then in the master of this view would also be different actions for each section in the sidebar from the right. Do I really need to open that many transactions each time this page is requested?

Roger commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:28:08 GMT

IMHO, checking if transaction is active isn't really reliable in case of zombied transactions. The client may think the transaction is active when it's actually not -> you'll loose the first exception. >

Ayende Rahien commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:26:57 GMT

Leonardo, No one solution is applicable for all scenarios. I would point out that usually for New action, you need some lookup data, but that is mostly beside the point

Leonardo commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:20:21 GMT

@NC I agree that session openings aren't expensive, but what about transaction opening? I don't think that if I have an action that does not access the db then the whole controller isn't going to access the db. Think of the case of a simple crud: The New action does not access the db (given the form is simple enough), but the Create action does. In this scenario, you would be opening a transaction in the New action and that is not needed.

NC commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:19:55 GMT

@Leonardo - Also it may feel awkward, but it's more logical, your session is a UoW, not a Collection of Work. If 1 action is saving a product to your shopping cart, and another action is querying the shopping cart. They are two completely separate things, and should be run under two separate units of work and two separate transactions.

NC commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 13:13:55 GMT

@Leonardo - Creating a session isn't expensive, it's cheap, it's not going to hurt performance by creating a session thats never used for an action that does not do any database access. However any action that does not require database access is probably a controller that does not require database access, so you wouldn't inherit the NH controller to begin with.

Scooletz commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:55:58 GMT

@Bogdan Marian, if so, the "child action problem" occur in the very same way, cause child action are run _after_ OnActionExecuted method. They are run during ActionResult.ExecuteResult. Using TransactionScope adds nothing the Ayende's solution, but perf problems mentioned by Ayende.

Leonardo commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:55:17 GMT

What about actions that do not require db access at all? You are opening a session and a transaction ALWAYS. Perhaps it's better to make the Session property "lazy" and when first issued open the session and the transaction. Then corresponding checks at ActionExecuted should be taken when that happens. It still feels a bit awkward to have different sessions and transactions for EACH child action. I think it's better to have a wider session (i.e. close it at ResultExecuted) in the parent action and use the same session and transaction for the child actions (since generally those actions will be read only), just to present data in the view.

Bogdan Marian commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:08:04 GMT

@Scooletz The TransactionScope has a a method, Complete, which is called if the underlying tx should be commited. If a rollback is needed, no method is called, thus will make the underlying tx to be rolled back - more info can be found on MSDN (see the link of my first comment). The Complete method will be called inside the OnActionExecuted method.

Scooletz commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:03:03 GMT

@Bogdan Marian: look at what @hazzik pointed out. Where would you commit your TransactionScope?

Ayende Rahien commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:02:32 GMT

Bodgan, If possible, avoid TransactionScope, it can lead to very bad perf.

Scooletz commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:01:05 GMT

@hazzik, child actions will run in their own transactions. Filters are applied on per action basis and child actions are run during result execution. If you got all the needed data in your session context, and you don't alter db in a child action, then everything is ok. Otherwise you have two (or more), separate transactions per request.

Bogdan Marian commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 12:00:34 GMT

@mag20 Since we are talking about a NHibernateActionFilter, this means the developer knows that the action manipulates a RDBMS, so even if it will run only one query, a transaction is needed (isolation from ACID is enforced by transactions). @ayende How about using a TransactionScope ( [msdn.microsoft.com/.../...ns.transactionscope.aspx](http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx))? If we have an action which spawns several child actions, each of these will just call the TransactionScope Complete in case everything is OK. Of course, this TransactionScope would have to be stored somewhere in order to make it available to all involved actions - maybe inside the HttpContext.Current ... Be using a TransactionScope, we can enlist other types of resourcs, eg MSQM, etc.

Ayende Rahien commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 11:46:36 GMT

Mag2, 1) you always need to use transactions with nhibernate 2) ambient session

mag20 commented on Refactoring toward frictionless & odorless code: What about transactions?

Tue, 12 Apr 2011 11:40:06 GMT

A couple of questions: 1. Is there a performance penalty for using transaction for all actions including the ones that are read-only. 2. If I use a BLL layer, how can I share the session used in UI and BLL?