TransactionScope does not rollback inside wcf service method, does roll back if called directly

Question

I am facing a problem that drives me crazy for couple of days now, hoping someone can help me. Here it is ;

I'm using EF4 with oracle database, using dotConnect for oracle from devart as provider. I have wcf service method which calls DeleteCabinet method below;

public void DeleteCabinet(string pRID)
{
    using(TransactionScope tranScope = new TransactionScope())
    {
        DBUtils.DeleteCabinetAndShelves(pRecordId);

        //throw exception to test record not deleted
        throw new Exception("xxx something has happened test xxx");

        tranScope.Complete();
    }
}

DBUtils.DeleteCabinetAndShelves looks like below;

public void DeleteCabinetAndShelves(string pRecordId)
{
    using(var context = new EdrmEntities())
    {
        var cabinet = context.Cabinets.Include("Shelves").Single(p => p.RID == pCabinetRID);

        //mark all cabinet shelves for deletion
        if (cabinet.Shelves != null)
        {
            foreach (var tempShelf in cabinet.Shelves.ToList())
            {
                context.DeleteObject(tempShelf);
            }
        }

        //mark cabinet for deletion
        context.DeleteObject(cabinet);

        //save 
        context.SaveChanges();
    }
}

when I call DeleteCabinet from within my test project, not a wcf call but direct method call, it works OK. It throws exception ,and transaction is rolled back. Thus no record is deleted from DB as expected

The problem is that when I call service method (which calls DeleteCabinet) from a client, the exception is thrown , but the record IS deleted from db. Transaction does not roll back !

seems like calling wcf method does not roll back transaction, but it seems crazy ( at least to me), does anybody know the reason why this might be happening ?

Thanks in advance

Answer 1

You tagged your post with the DevArt and DotConnect tags... I wonder if this is a bug in the DevArt providers rather than something inherent to WCF / Entity Framework / System.Transactions. You could test the theory by seeing if it happens with a ObjectContext that is using the built-in SQL Server Provider (or even Oracle's own EF provider that was recently released) and see if the issue still occurs. That is the only thing I can think of since the code seems 100% correct.

Answer 2

Thanks to @Rabid and @luksans constructive comments problem is solved, and it turned out it has nothing to do with wcf or devart's provider being buggy

Here's the thing ; wcf service (which did not rollback), and integration test (which did) are inside different projects, thus config files are different. They got out of sync sometime in past, and the difference is in Enlist=false part. So wcf project's connection string has Enlist=false while test project does not. That's how the illusion of WCF failing transaction was born.

Removing Enlist=false from wcf project's connection string fixed the issue.