I'm facing following problem:
In my project, I have done error logging into the same DB, as the application is using. That means, that if error occurs, then in each catch, there is the error stored into DB.
The problem is however, when using transactions. When error occurs, the tran rollbacks, but it also rollbacks the error logged, like in this scenario:
this is public service, used to save client changes.
public UpdateClient(client)
{
try
{
TransactionScope scope0 = new TransactionScope();
// some code
scope0.Complete();
}
catch(Exception ex)
{
Logger.LogException(ex); //log the exception into DB
}
}
this is public service, used to multiple clients changes:
public void UpdateClients(clients)
{
try
{
TransactionScope scope1 = new TransactionScope();
foreach (client c in clients)
{
UpdateClient(c);
}
scope1.Complete();
}
catch (Exception ex)
{
Logger.LogException(ex);
}
}
What happend here is, that if using UpdateClients(), and if error occurs in UpdateClient(), then it is logged into DB in UpdateClient() catch block. The scope0 is rollbacked, and doesnt affect the logged exception. But the scope1 is also rollbacked, and will rollback also the exception stored in DB in the UpdateClient() catch block.
I know, that there are options like store the errors in different DB and so on, but this is unfortunately not acceptible in current state of development.
Is there any way, how to solve this problem without major changes?
You can collect the exceptions while updating and insert them into the db outside the transaction scope:
public UpdateClient(client, bool logErrors = true)
{
try
{
TransactionScope scope0 = new TransactionScope();
// some code
scope0.Complete();
}
catch(Exception ex)
{
Logger.EnlistException(ex); // collect the exception
}
if (logErrors) Logger.WriteEnlistedExceptions();
}
public void UpdateClients(clients)
{
try
{
TransactionScope scope1 = new TransactionScope();
foreach (client c in clients)
{
UpdateClient(c, false);
}
scope1.Complete();
}
catch (Exception ex)
{
Logger.EnlistException(ex);
}
Logger.WriteEnlistedExceptions();
}
public partial class Logger
{
private static List<Exception> _exceptionList = new List<Exception>();
public static void EnlistException(Exception ex)
{
_exceptionList.Add(ex);
}
public static void WriteEnlistedExceptions()
{
foreach(Exception ex in _exceptionList)
LogException(ex);
_exceptionList.Clear();
}
}
This is of course not yet thread safe. The distinction between a call from UpdateClient or UpdateClients can be made by the stack trace of the exception.
As the answers to the question linked by Micky show, there is no way to prevent the rollback by the outer scope.
[EDIT] added logErrors flag
So I found an acceptable solution. The code will be implemented in internal method without transaction and will enlist exception in catch. Then usage is as follows:
internal UpdateClient(client)
{
try
{
// some code
}
catch(Exception ex)
{
Logger.EnlistException(ex); // collect the exception
}
}
public UpdateClient(client)
{
try
{
TransactionScope scope0 = new TransactionScope();
//call internal UpdateClient
/*internal*/ UpdateClient(client);
scope0.Complete();
}
catch(Exception ex)
{
Logger.WriteEnlistedExceptions(ex); // collect and write the exception
}
}
public void UpdateClients(clients)
{
try
{
TransactionScope scope1 = new TransactionScope();
foreach (client c in clients)
{
/*interanl*/ UpdateClient(c);
}
scope1.Complete();
}
catch (Exception ex)
{
Logger.WriteEnlistedExceptions(ex);
}
}
public partial class Logger
{
private static List<Exception> _exceptionList = new List<Exception>();
public static void EnlistException(Exception ex)
{
_exceptionList.Add(ex);
}
public static void WriteEnlistedExceptions()
{
foreach(Exception ex in _exceptionList)
LogException(ex);
_exceptionList.Clear();
}
}
Related
I have a lot of classes with this structure as you can see:
public class OrganizationUserRepository : IOrganizationUserRepository
{
private DataContext _ctx;
public OrganizationUserRepository(DataContext ctx)
{
_ctx = ctx;
}
public bool Add(OrganizationUser entity)
{
try
{
_ctx.OrganizationUsers.Add(entity);
_ctx.SaveChanges();
return true;
}
catch (Exception ex)
{
// TODO log this error
return false;
}
}
public bool Edit(OrganizationUser entity)
{
try
{
OrganizationUser Edited = _ctx.OrganizationUsers.Where(i => i.Id == entity.Id).First();
_ctx.Entry(Edited).CurrentValues.SetValues(entity);
_ctx.SaveChanges();
return true;
}
catch (Exception ex)
{
// TODO log this error
return false;
}
}
public bool Remove(string id)
{
try
{
Int64 Id = Int64.Parse(id);
OrganizationUser obj = _ctx.OrganizationUsers.Where(i => i.Id == Id).First();
_ctx.OrganizationUsers.Remove(obj);
_ctx.SaveChanges();
return true;
}
catch (Exception ex)
{
// TODO log this error
return false;
}
}
}
The db context in constructor is injected by ninject .as you can see it just one of my classes .and i have multi classes like this in another services that use a single DB .(WCF Service).But i get this error in my wcf tracelog :
ExecuteReader requires an open and available Connection. The connection's current state is open.
I am using EF code first .
I found this Wrap DbContext db = new DbContext() inusing statement. And i want to know should i use this ,if Yes how can i change my class structure to use using in my code ?
I used public Readonly DbContext .i just remove readonly and everything work fine.
I have a class which contains several methods.
One of the methods runs in a while loop (MainMethod).
I call out to helper methods in the same class from MainMethod.
The Try Catch is contained within MainMethod where most of the execution occurs.
If an exception occurs in a helper method which doesn't contain a Try Catch, will it be caught further up? i.e. inside MainMethod which called the helper method.
class Class1
{
public MainMethod()
{
while (true)
{
try
{
// ...
// ...
// ...
HelperMethod();
// ...
// ...
}
catch (Exception e)
{
// Console.WriteLine(e.ToString());
// logger.log(e.ToString();
// throw e;
// ...
}
}
}
public HelperMethod()
{
// No Try Catch
// if (today == "tuesday") program explodes.
}
}
Thanks.
Yes. If a method has no try/catch block it will "bubble up" the stack and be caught by the next handler up the chain. If there is no handler, that's when your program terminates because an exception was "unhandled".
Yes it will. Something like this:
public class Helper
{
public void SomeMethod()
{
throw new InvalidCastException("I don't like this cast.");
}
public void SomeOtherMethod()
{
throw new ArgumentException("Your argument is invalid.");
}
}
public class Caller
{
public void CallHelper()
{
try
{
new Helper().SomeMethod();
}
catch (ArgumentException exception)
{
// Do something there
}
catch (Exception exception)
{
// Do something here
}
try
{
new Helper().SomeOtherMethod();
}
catch (ArgumentException exception)
{
// Do something there
}
catch (Exception exception)
{
// Do something here
}
}
}
Note that if caller application handles that specific type of exception, specific catch block will be called.
IMHO, it is good to handle specific exceptions that may be thrown by methods you call from your code. However, that also means that author of method you are calling created a decent document sharing exceptions that we need to expect from his code.
This is my query where I'm returning an IEnumerable<CreditCardTransaction> to iterate through.
public partial class CreditCardTransaction
{
public static IEnumerable<CreditCardTransaction> GetUnprocessedTransactions()
{
try
{
using (var context = new SuburbanEntities())
{
return from trans in context.CreditCardTransactions
where trans.IsPublished == false
select trans;
}
}
catch (Exception ex)
{
Logging.Log("An error occurred.", "GetUnprocessedTransactions",Apps.ServicesConfig, ex);
return null;
}
}
}
This is where I am modifying those transactions once I have processed them:
public void ProcessFile()
{
try
{
_client = new TruckServiceClient();
_globalSetting = new GlobalSetting();
var unprocesstransactions = CreditCardTransaction.GetUnprocessedTransactions();
foreach (var creditCardTransaction in unprocesstransactions)
{
creditCardTransaction.IsPublished = ProcessTransaction(creditCardTransaction);
}
}
catch (Exception ex)
{
Logging.Log("An error occurred.", "ProcessCreditCardTransactions.ProcessFile", Apps.RemoteServices, ex);
}
}
I am modifying the transactions here:
creditCardTransaction.IsPublished = ProcessTransaction(creditCardTransaction);
But once I have saved them, can I update the entity directly or do I need to create another method where I pass this information back in?
The problem you don't have access to the context. Here you have some examples how to do:
https://github.com/geersch/EntityFrameworkObjectContext
If you're developing Asp.Net app, you'll have some drawbacks illustreted in this article:
http://dotnetslackers.com/articles/ado_net/Managing-Entity-Framework-ObjectContext-lifespan-and-scope-in-n-layered-ASP-NET-applications.aspx#managing-objectcontext-instantiation
I am trying to implement Entity Framework in my application and i should be able to commit and rollback the changes manually.
First time when i execute the update statement it updates the table successfully and i am able to rollback the changes. This is correct
But second time when i execute the update statement, it updates the table successfully and also commits the changes. So I am unable to rollback manually. This is wrong
Please let me know why it is happening and how to solve this issue.
The below code is just sample to reproduce my problem.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Common;
using System.Data;
namespace EFTest
{
public class DBOperations
{
NorthwindEntities NorthwindContext;
DbTransaction transObject;
public DBOperations()
{
}
public void ConnectDB()
{
try
{
if (NorthwindContext == null)
{
NorthwindContext = new NorthwindEntities();
if (NorthwindContext != null && NorthwindContext.Connection.State != ConnectionState.Open)
{
NorthwindContext.Connection.Open();
transObject = NorthwindContext.Connection.BeginTransaction(IsolationLevel.ReadUncommitted);
}
}
}
catch (Exception ex)
{
throw new Exception("Database Error " + ex.Message);
}
}
public int disconnect()
{
if (NorthwindContext != null && transObject != null)
{
try
{
transObject.Rollback();
}
catch (Exception)
{
}
transObject.Dispose();
NorthwindContext.Connection.Close();
NorthwindContext.Dispose();
}
return 0;
}
public void CommitTransaction()
{
if (NorthwindContext != null && transObject != null)
{
try
{
transObject.Commit();
}
catch (Exception)
{
}
}
}
public void RollbackTransaction()
{
if (NorthwindContext != null && transObject != null)
{
try
{
transObject.Rollback();
}
catch (Exception)
{
}
}
}
public int UpdateDB()
{
int _returnVal = 0;
try
{
NorthwindContext.ExecuteStoreCommand("UPDATE Orders SET OrderDate = GETDATE() WHERE OrderID = '10248'");
}
catch (Exception ex)
{
throw new Exception("Database Error " + ex.Message);
}
return _returnVal;
}
}
public class program
{
public program()
{
//Establishing the connection.
DBOperations _DBOperations = new DBOperations();
_DBOperations.ConnectDB();
//Update the datebase
_DBOperations.UpdateDB(); //Update the database but it doesn't commit the changes.
//Issue Rollback to rollback the transaction.
_DBOperations.RollbackTransaction(); //Successfully Rollbacks the database changes.
//Again Update the datebase
_DBOperations.UpdateDB(); //Update the database it commits the changes.
//Issue Rollback to rollback the transaction.
_DBOperations.RollbackTransaction(); //Rollback fails.
}
}
}
With TransactionScope Your DbOperations could look like this:
public class DBOperations : IDisposable
{
NorthwindEntities _context;
private TransactionScope _transactionScope;
public DBOperations()
{
this.Initialize();
}
private void Initialize()
{
try
{
this.Dispose();
this._transactionScope = new TransactionScope();
this._context = new NorthwindEntities();
// no need to open connection. Let EF manage that.
}
catch (Exception ex)
{
throw new Exception("Database Error " + ex.Message);
}
}
public void RollbackTransaction()
{
try
{
this._transactionScope.Dispose();
this._transactionScope = null;
this.Dispose();
this.Initialize();
}
catch (Exception)
{
// TODO
}
}
public int UpdateDB()
{
int _returnVal = 0;
try
{
this._context.ExecuteStoreCommand("UPDATE Orders SET OrderDate = GETDATE() WHERE OrderID = '10248'");
}
catch (Exception ex)
{
throw new Exception("Database Error " + ex.Message);
}
return _returnVal;
}
public void Dispose()
{
if (this._transactionScope != null)
{
this._transactionScope.Complete();
this._transactionScope.Dispose();
}
if (this._context != null) this._context.Dispose();
}
}
And the program:
public class program
{
public program()
{
using (DBOperations dbOperations = new DBOperations())
{
dbOperations.UpdateDB(); // Update the database no commit.
dbOperations.RollbackTransaction(); // Rollback.
dbOperations.UpdateDB(); // Update the database no commit.
dbOperations.RollbackTransaction(); // Rollback.
} // Commit on Dispose.
}
}
A connection that is opened within the scope of a TransactionScope automatically enlists in the transaction. The transaction is only committed by calling Commplete(). Disposing or unhandled exceptions will cause a rollback.
If you do more than just a store command, as in changing objects and relying on the context's change tracking, you may to implement a retry mechanism in stead of just discarding the context and the changes.
You need to assign new transaction after commit or rollback of transaction .
public program()
{
//Establishing the connection.
DBOperations _DBOperations = new DBOperations();
_DBOperations.ConnectDB();
//Update the datebase
_DBOperations.UpdateDB(); //Update the database but it doesn't commit the changes.
//Issue Rollback to rollback the transaction.
_DBOperations.RollbackTransaction(); //Successfully Rollbacks the database changes.
_DBOperations.ConnectDB(); //you need to assign new transaction because your last
//transaction is over when you commit or roll back
_DBOperations.UpdateDB(); //Update the database it commits the changes.
//Issue Rollback to rollback the transaction.
_DBOperations.RollbackTransaction(); //Rollback fails.
}
Is there any difference between these tow pieces of code & which approach is better.
try
{
using()
{
//Do stuff
}
}
catch
{
//Handle exception
}
using()
{
try
{
//Do stuff
}
catch
{
//Handle exception
}
}
There are differences, but it namely boils down to the fact that a using block creates it own try and scope blocks.
try
{
using(IDisposable A = GetDisposable())
{
//Do stuff
}
}
catch
{
//Handle exception
// You do NOT have access to A
}
using(IDisposable A = GetDisposable()) //exception here is uncaught
{
try
{
//Do stuff
}
catch
{
//Handle exception
// You DO have access to A
}
}
There's a difference between these blocks. In the second case the exception won't be caught if it is thrown in the using() line (for example instantiating an IDisposable object and the constructor throws an exception). Which one is better will depend on your specific needs.
Yes. In the first, the resource you are "using" will be disposed before the catch block is executed. In the later, it will be disposed afterwards. Moreover, the "foo" statement isn't under the scope of the catch clause. A "using" block is almost syntactic sugar such that
using (foo)
{
}
is
try
{
foo;
}
finally
{
foo.Dispose();
}
Which behaviour is "better" is not obvious without context.
Ultimately, you could combine both methods to overcome both drawbacks:
IFoo f;
try{
f = new Foo();
f.Bar();
catch{
// Do something exceptional with f
} finally{
if(f != null) f.Dispose();
}
As mentioned above, only the first method will catch exceptions in the IDisposable object's initialization, and will have the object in-scope for the catch block.
In addition, the order of operations for the catch and finally blocks will be flipped depending on their nesting. Take the following example:
public class MyDisposable : IDisposable
{
public void Dispose()
{
Console.WriteLine("In Dispose");
}
public static void MethodOne()
{
Console.WriteLine("Method One");
using (MyDisposable disposable = new MyDisposable())
{
try
{
throw new Exception();
}
catch (Exception ex)
{
Console.WriteLine("In catch");
}
}
}
public static void MethodTwo()
{
Console.WriteLine("Method Two");
try
{
using (MyDisposable disposable = new MyDisposable())
{
throw new Exception();
}
}
catch (Exception ex)
{
Console.WriteLine("In catch");
}
}
public static void Main()
{
MethodOne();
MethodTwo();
}
}
This will print:
Method One
In catch
In Dispose
Method Two
In Dispose
In catch
I presume you mean:
using (var x = new Y(params))
{
}
In both cases? Then the obvious difference is the scope of x. In the second case, you could access x in the catch clause. In the first case, you could not.
I'll also take the opportunity to remind you not to "handle" an exception unless you can really do something about it. That includes logging the exception, which would be ok, unless the environment you're operating in does the logging for you (as ASP.NET 2.0 does by default).