7

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

rayback2
  • 81
  • 5
  • I believe this would largely depend on your WCF bindings and whether they have transactional support. Update your question to reveal your bindings and your WCF service contract declarations. – Rabid Mar 06 '12 at 11:27
  • Correct me if I'm wrong, but since my service is not participating in a transaction started by a client (no wcf transaction in that sense) ,those settings should be irrelevant in this scenario. i.e : client call to service method is not inside transactionscope, it's the server that starts and completes transaction as seen above. – rayback2 Mar 06 '12 at 11:48
  • 1
    Ohh, I see, thats odd. Do you allow WCF to fault the channel or do you handle the exception in the WCF service call and send a result back to the client? Is `EdrmEntities` constructing it's own `EntityConnection` or is it perhaps using a shared connection that has been automatically enlisted in an implicit transaction outside your `TransactionScope`? – Rabid Mar 06 '12 at 12:25
  • Hi . `..class EdrmEntities: ObjectContext { ... ` and ctor calls base as following `EdrmEntities():base("name=EdrmEntities", "EdrmEntities")`. Btw how can I understand if shared connection,if used, is enlisted in an implicit transaction outside of my scope ? – rayback2 Mar 06 '12 at 12:45
  • About faulting : I tried it both ways catching exception on server and letting it fault the channel, both ways result is the same. – rayback2 Mar 06 '12 at 12:55
  • 2
    If you derive from `ObjectContext`, using a named connection string (`name=EdrmEntities`), then I believe a new connection is opened (not a shared one). I guess the best way to determine if there is an ambient transaction outside your `TransactionScope` is to check the `Transaction.Current` property before your new scope is created; automatic transaction enlistment is specific to the configuration of the connection string for your provider ([Enlist=false](http://msdn.microsoft.com/en-us/library/0524954e%28v=vs.90%29.aspx)). Hmmm... – Rabid Mar 06 '12 at 14:03
  • I noticed I did not provide my connection string anywhere, my bad. Here it is : `connectionString="metadata=res://*/Model.EdrmModel.csdl|res://*/Model.EdrmModel.ssdl|res://*/Model.EdrmModel.msl;provider=Devart.Data.Oracle;provider connection string="User Id=XXX;Password=YYY;Server=ZZZ;Max Pool Size=3000;Pooling=True;Enlist=false;Transaction Scope Local=true""` – rayback2 Mar 06 '12 at 14:56
  • 1
    As a previous commenter alluded to, your use of `Enlist=false` in that connection string may be the culprit. I believe that option means that the any connection you create will not enlist itself in the transaction managed by the thread's current `TransactionScope` (or `Transaction.Current`). Try changing it to `Enlist=true`. – luksan Mar 06 '12 at 17:55

2 Answers2

3

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.

luksan
  • 7,661
  • 3
  • 36
  • 38
  • Tried with Oracle's provider , and it seems working. I am figuring if it was a bug in devarts provider, it'd be uncovered long before (and fixed), so I am thinking it must have something to do with the configuration . Will contact their support team for the issue. ` – rayback2 Mar 06 '12 at 14:54
1

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.

rayback2
  • 81
  • 5