Hi All,

I've got a very quick and dirty solution for dealing with database errors in ASP.Net pages. The idea is to start a transaction when the requests starts and then add every LLBLGen entity/action to it until the rendering starts (no more db action after that) and commit it. This way if I would have any errors during the page request al actions, which might depend on each other or update multiple entities, would be undone.

Since each request is a specific action this felt like a starting point, but also like "cowboy programming". Has anyone one decided to do this before, and done actually done this, or can tell my this is such a bad idea (as it feels that way)

thanks, Gab

transaction per view is a common scenario for web based programming. I began using this for all my web apps this year. it makes sense since each request is atonomous. on BeginRequest open the connection and start a transaction. On end request commit the transaction (if it's still open) and dispose of the adapter. On error rollback transaction (if open).

this make it much more simple to manage transactions, entity state and other db connections.

Thanks for your comment. I would like to hear if others do this too, or some resource with some more in depth info on this.

Also, you probably use 1 connection in the Adapter scenario, we use self-servicing, would there be an option too to have everything going into 1 transaction without manually adding it?

gabrielk wrote:

Hi All,

I've got a very quick and dirty solution for dealing with database errors in ASP.Net pages. The idea is to start a transaction when the requests starts and then add every LLBLGen entity/action to it until the rendering starts (no more db action after that) and commit it. This way if I would have any errors during the page request al actions, which might depend on each other or update multiple entities, would be undone.

Since each request is a specific action this felt like a starting point, but also like "cowboy programming". Has anyone one decided to do this before, and done actually done this, or can tell my this is such a bad idea (as it feels that way)

It is a bad idea. Transactions aren't free. They consume resources and lock other operations. I'd say use transactions only when you really need them and only as long as they are needed (end them asap).

I haven't used SS, only adapter. I don't believe this model would work with SS because the entities manage the adapter internally.

It is a bad idea. Transactions aren't free. They consume resources and lock other operations. I'd say use transactions only when you really need them and only as long as they are needed (end them asap).

yes it is a good practice to only use transactions when necessary. However there are trade-offs between performance and maintainability. premature optimization can kill maintainability. By having the adapter/transaction within one object this drastically simplifies my architecture. if this becomes a problem later on then I will refactor.

here is a similar thread http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=14129