Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > ASP.NET and ASP > Other ASP.NET > BOOK: Professional ASP.NET Design Patterns
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
BOOK: Professional ASP.NET Design Patterns
This is the forum to discuss the Wrox book Professional ASP.NET Design Patterns by Scott Millett; ISBN: 978-0-470-29278-5
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional ASP.NET Design Patterns section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developersí questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old November 20th, 2018, 08:00 AM
Registered User
Points: 8, Level: 1
Points: 8, Level: 1 Points: 8, Level: 1 Points: 8, Level: 1
Activity: 100%
Activity: 100% Activity: 100% Activity: 100%
 
Join Date: Nov 2018
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default Unit of Work and TransactionScope

I've been implementing some of the patterns from Chapter 7, including the Unit of Work + repository for Dapper (and SQL db persistence), and I encountered an issue around performance.

The use of TransactionScope in the UoW, while very simple and elegant, seems to cause a huge performance overhead. In an integration test project where I add an aggregate with 1000 child objects, using TransactionScope makes the test execution time increase about ten-fold. In order to overcome this, I added some additional code to the UnitOfWork and Repository classes to allow the UnitOfWork to open the connection and begin the transaction on the first of the repositories registered with it - this transaction is then passed into each of the peristence methods so that they can make use of it.

This makes the UoWRepo interface looks like so:

Code:
    public interface IUnitOfWorkRepository
    {
        Task<IDbTransaction> BeginTransaction();
        Task PersistCreationOf(IAggregate aggregate, IDbTransaction tran);
        Task PersistUpdateOf(IAggregate aggregate, IDbTransaction tran);
    }
And in the repo implementation:

Code:
    public async Task<IDbTransaction> BeginTransaction()
    {
        var connection = GetConnection();
        await connection.OpenAsync();
        return connection.BeginTransaction();
    }
And finally, in the UoW Commit method:

Code:
	
	//Having kept tabs on the first repo registered, now begin tran
    var tran = await _initialRepository.BeginTransaction();
    var connection = tran.Connection;

    using (connection)
    {
        using (tran)
        {
            foreach (var entity in _addedEntities.Keys)
            {
                await _addedEntities[entity].PersistCreationOf(entity, tran);
            }

            foreach (var entity in _changedEntities.Keys)
            {
                await _changedEntities[entity].PersistUpdateOf(entity, tran);
            }

            tran.Commit();
        }
        connection.Close();
    }
The persistence methods then simply make use of the tran, and execute against the connection associated with the tran. This works, and I see vastly improved performance.

However, I wanted to know whether anyone else had encountered any performance issues with TransactionScope (I had anticipated *some* overhead, but not this much), and whether I am guilty of any error in the above approach. I am not concerned about distributed/escalated transactions, etc. so don't actually need a lot of the added value of TransactionScope.

Thoughts appreciated!
Reply With Quote
  #2 (permalink)  
Old November 20th, 2018, 03:47 PM
Registered User
Points: 8, Level: 1
Points: 8, Level: 1 Points: 8, Level: 1 Points: 8, Level: 1
Activity: 100%
Activity: 100% Activity: 100% Activity: 100%
 
Join Date: Nov 2018
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Oh, my mistake. I wasn't enlisting the dapper operations in the transaction correctly.
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Chapter 7: Unit Testing with the Unit Testing Framework antwarpes BOOK: Professional Application Lifecycle Management with Visual Studio 2010 3 September 25th, 2011 09:47 AM
Chapter 7 Unit Testing with the Unit Test Framework - examples blaurence46 BOOK: Professional Application Lifecycle Management with Visual Studio 2010 1 September 24th, 2011 11:07 AM
NHibernate and the Unit of Work BrianOConnell BOOK: Professional ASP.NET Design Patterns 5 November 21st, 2010 09:04 AM
Using TransactionScope in the BLL? tdewey BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 2 July 8th, 2009 06:02 PM
TransactionScope and Shared Web Hosting Chris_H BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 3 May 6th, 2007 11:17 PM



All times are GMT -4. The time now is 04:41 AM.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.