Set Transaction Scope on DP_Fetch

Set Transaction Scope on DP_Fetch

Old forum URL: forums.lhotka.net/forums/t/4043.aspx


SethSpearman posted on Friday, December 14, 2007

Do you guys decorate your DataPortal_Fetch with a transaction scope?  What is the reason for that (since it a read)?  Are there dangers to not doing it?

Seth

JoeFallon1 replied on Friday, December 14, 2007

No.

I rarely read using a transaction.

I think there might be rare cases where it is useful though.

Joe

 

RockfordLhotka replied on Monday, December 17, 2007

I've had a couple people (when I'm speaking at conferences) insist that all reads must be transactionall protected.

And without transactional protection they are correct, in that there's a tiny chance that you'd break isolation and get some data that is in the middle of an update. Though even that isn't as bad as it sounds, because each row is always going to be consistent - it is just that you might retrieve a list of rows and row 1 is pre-update and row 2 is post-update. Odds are that neither you nor your user would ever be aware of this issue.

Using a transaction on read has a performance impact, and most people simply aren't willing to suffer a full-time perf penalty for a rare edge case that is likely to have no impact on the app in any meaningful sense.

Ultimately of course, the choice is yours Smile [:)]

SethSpearman replied on Monday, December 17, 2007

Thanks for the reply Rocky.  I am going to be removing the transaction scope from the fetch soon.

I love CSLA. 

Seth

amselem replied on Tuesday, December 18, 2007

If you're using Sql Server 2005 you can use the Snapshot isolation level for reads. This way reading won't create any locks on tables,  and any concurrency issues would resolve using row versioning.

However I don't see a way to specify isolation level with the current implementation of TransactionalAttribute, you should use the "Manual" option and handle the transactions yourself specifying the isolation level ...

Copyright (c) Marimer LLC