Back to list
Views:   19.1K
Replies:  5
Archived

Static data access objects variables in ActionService for standalone application

Hi,

When the Patterns In Action sample is run a standalone mode, should the Static data access objects variable changed to non static ones?

 // Create static data access objects
 private static readonly ICategoryDao _categoryDao = DataAccess.CategoryDao;
 private static readonly IProductDao _productDao = DataAccess.ProductDao;
 private static readonly ICustomerDao _customerDao = DataAccess.CustomerDao;
 private static readonly IOrderDao _orderDao = DataAccess.OrderDao;
 private static readonly IOrderDetailDao _orderDetailDao = DataAccess.OrderDetailDao;
If not, would it run into threading concurrency issues of the ObjectContect of the entity framework? e.g. race conditons from different threads of one application domain in IIS?

Thanks
London UK, Mar 09, 2011
Reply 1
Mr London UK:

I would recommend against what you are suggesting.  From an OO perspective is seems wrong for two or more methods to coordinate the lifetime of an object instance (the context) until someone decides to dispose of it. The relative performance gains do not compare to the potential risks.

Hope this helps.



Dan McMillan, Mar 10, 2011
Reply 2
Hi Dan,

Thanks for your reply, The explanation is very helpful.

If we modify the CustomerDAO to have a single instance of ObjectContext using singleton pattern, and dispose it explicitly rather than using the using(...) syntax.

We could then have a CustomerDAO instance created, call getCustomers, updateCustomers, disposed the ObjectContext. In this way,
we can reuse the ObjectContext among method calls.

In this case, should we change

private static readonly ICustomerDao _customerDao = DataAccess.CustomerDao;
to non-static ones?

Thanks
London UK, Mar 10, 2011
Reply 3
This is a good question.

Indeed, the Patterns in Action application works with numerous static classes. However, each thread has its own stack and non-static local variables are placed on the stack. Global and static variables can cause problems in a multi-threaded environment but that is not the case with local variables.

If you look at the methods of the DOAs each creates (and destroys) their own ObjectContext as a local variable. So, there is no risk of race conditions or other concurrency issues. I have included an arbitrary example from the Design Pattern Framework: the GetCustomer method on the EntityCustomerDao class.

public Customer GetCustomer(int customerId)
{
  using (var context = DataObjectFactory.CreateContext())
  {
    return Mapper.Map(context.CustomerEntities.FirstOrDefault(c => c.CustomerId == customerId));
  }
}

Ha, you may say, but the above DataObjectFactory is a static class and CreateContext is a static method, which is true.  However, if you look at CreateContext (listed below), you see that it creates a new instance of the Context (named ActionEntities) each time it is called. So each DOA method will have its own unique context. 


public static ActionEntities CreateContext()
{
   return new ActionEntities(_connectionString);
}

I hope this helps.

Dan
Data & Object Factory, LCC


 
 
Dan McMillan, Mar 10, 2011
Reply 4
As the static variable has only one instance in the memory, all the request are using the same ObjectContext of the entity framework.

If one request dispose the ObjectContext while another request is in the middle of using it, will that not cause unexpected results?
London UK, Mar 10, 2011
Reply 5
I guess no, because for static variables when it is initialized at declaration time, is thread safe.   I haven't yet faced any issue with this yet.

More info at   http://stackoverflow.com/questions/1270565/static-initialization-guarantees-singleton-thread-safety-c


Other expert opinions awaited!.
Rajesh Pillai, Mar 09, 2011


Stay Inspired!
Join other developers and designers who have already signed up for our mailing list.
Terms     Privacy     Licensing       EULA       Sitemap      
© Data & Object Factory, LLC.
Made with    in Austin, Texas.      Vsn 1.3.0