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
No.
I rarely read using a transaction.
I think there might be rare cases where it is useful though.
Joe
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 [:)]](/emoticons/emotion-1.gif)
Thanks for the reply Rocky. I am going to be removing the transaction scope from the fetch soon.
I love CSLA.
Seth
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