I am trying to implement a reoccurring timer function asp.net. I am not able to create a windows service as I host the site on a shared environment and therefore do not have access.
I have read various ways of achieving this each with their own advantages/disadvantages. The cache object approach seemed promising but does seem like a hack.
I have been trying to implement a httphandler that will spin up a single System.Threading.Timer object to cycle every minute and do some work. Possibly queuing up other work items.
Here is what I have so far:
public class Scheduler : IHttpHandler
{
protected static TimerCallback tcb = null;
protected static Timer timer = null;
static Scheduler()
{
tcb = new TimerCallback(DoWork);
timer = new Timer(tcb, null, TimeSpan.Zero, new TimeSpan(0, 0, 1, 0));
}
private static void DoWork(Object stateInfo)
{
}
public void ProcessRequest(HttpContext context)
{
}
public bool IsReusable
{
get { return false; }
}
}
I read here that you need to mindful of the timer not being disposed of when the appDomain unloading. He does imply that it is only a problem if you are invoking native code which I am not. I couldn't figure out how to tie into the application_end event to dispose of the timer from within the handler.
My question is, Is the above approach way off the mark? Is there a better way to do this? Would it make more sense to ditch the static variables and store the timer in application state?
Sorry I need informed opinions. I feel like i'm going around in circles.
Thanks,
This is a complete hack, hope I don't get down voted! - but you could develop a component which is part of your web deployment which makes an Http request to a handler on the same site - this way (I guess) your app would be able to call itself to ensure it wasn't unloaded. see the WebClient class - sorry not sure which namespace off the top of my head.
If you do this you'll need to think about how it's restarted if it's taken down for any reason; and I'm not sure if you'll get any weird behaviour if you have a web application that stays up for really long periods of time.
Related
How can I dispose and re-instantiate a singleton with Prism/DryIoC in Xamarin Forms?
I'm working with Azure Mobile Apps for offline data. Occasionally, I need to delete the local sqlite database and re-initialize it. Unfortunately the MobileServiceClient occasionally holds the db connection open and there's no method exposed to close it. The suggested solution (https://github.com/Azure/azure-mobile-apps-net-client/issues/379) is to dispose of MobileServiceClient. Only problem is that is registered with DryIoC as a singleton.
I'm not overly familiar with DryIoC, or Prism and Forms for that matter... But for the life of me, I can't see a way to do this.
I did cook up a pretty elaborate scheme that almost worked.
In my ViewModel method, when I needed the db freed up, I fired off an event -
_eventAggregator.GetEvent<RegisterDatabaseEvent>().Publish(false);
Then in App.xaml.cs, I wired up a listener and a handler like so -
_eventAggregator.GetEvent<RegisterDatabaseEvent>().Subscribe(OnRegisterDatabaseEventPublished);
private void OnRegisterDatabaseEventPublished()
{
Container.GetContainer().Unregister<IAppMobileClient>();
Container.GetContainer().Unregister<IMobileServiceClient>();
Container.GetContainer().Register<IMobileServiceClient, AppMobileClient>(new SingletonReuse());
Container.GetContainer().Register<IAppMobileClient, AppMobileClient>(new SingletonReuse());
_eventAggregator.GetEvent<RegisterDatabaseCompletedEvent>().Publish(register);
}
Lastly, back in the ViewModel constructor, I had a final listener that handled the event coming back from App.xaml and finished processing.
_eventAggregator.GetEvent<RegisterDatabaseCompletedEvent>().Subscribe(OnRegisterDatabaseCompletedEventPublished);
So the amazing thing is that this worked. The database was able to be deleted and all was good. But then I navigated to a different page and BOOM. DryIoC said it couldn't wire up the ViewModel for that page. I assume the unregister/register jacked up DryIoC for all injection... So how can I accomplish what needs to be done?
FINAL SOLUTION
Thanks so much to dadhi for taking the time to help. You are certainly a class act and I'm now considering using DryIoC elsewhere.
For anyone who stumbles on this, I'm posting the final solution below. I'll be as verbose as I can to avoid any confusion.
First, in my App.xaml.cs, I added a method for registering my database.
public void RegisterDatabase(IContainer container)
{
container.RegisterMany<AppMobileClient>(Reuse.Singleton,
setup: Setup.With(asResolutionCall: true),
ifAlreadyRegistered: IfAlreadyRegistered.Replace,
serviceTypeCondition: type =>
type == typeof(IMobileServiceClient) || type == typeof(IAppMobileClient));
}
I simply add a call to that method in RegisterTypes in place of registering the types in there directly.
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.GetContainer().Rules.WithoutEagerCachingSingletonForFasterAccess();
...
RegisterDatabase(containerRegistry.GetContainer());
...
}
Note also the added rule for eager caching, per dadhi.
Later on when I need to release the database in the ViewModel... I kick things off by resetting my local db variable and sending an event to App.xaml.cs
_client = null;
_eventAggregator.GetEvent<RegisterDatabaseEvent>().Publish(true);
In App.xaml.cs, I have subscribed to that event and tied it to the following method.
private void OnRegisterDatabaseEventPublished()
{
RegisterDatabase(Container.GetContainer());
_eventAggregator.GetEvent<RegisterDatabaseCompletedEvent>().Publish(register);
}
Here I just call RegisterMany again, exactly the same as I do when the app starts up. No need to unregister anything. With the setup and ifAlreadyRegistered arguments (thanks, dadhi!), DryIoC allows the object to be replaced. Then I raise an event back to the VM letting it know the database has been released.
Finally, back in the ViewModel, I'm listening for the completed event. The handler for that event updates the local copy of the object like so.
_client = ((PrismApplication)App.Current).Container.Resolve<IAppMobileClient>();
And then I can work with the new object, as needed. This is key. Without setting _client to null above and resolving it again here, I actually ended up with 2 copies of the object and calls to methods were being hit 2x.
Hope that helps someone else looking to release their Azure Mobile Apps database!
I am not sure how exactly XF handles these things.
But in DryIoc in order for service to be fully deleted or replaced it need to be registered with setup: Setup.With(asResolutionCall: true). Read here for more details: https://bitbucket.org/dadhi/dryioc/wiki/UnregisterAndResolutionCache#markdown-header-unregister-and-resolution-cache
Update
Here are two options and considerations that work in pure DryIoc and may not work XF. But it probably may help with solution.
public class Foo
{
public IBar Bar { get; private set; }
public Foo(IBar bar) { Bar = bar; }
}
public interface IBar {}
public class Bar : IBar {}
public class Bar2 : IBar { }
[Test]
public void Replace_singleton_dependency_with_asResolutionCall()
{
var c = new Container(rules => rules.WithoutEagerCachingSingletonForFasterAccess());
c.Register<Foo>();
//c.Register<Foo>(Reuse.Singleton); // !!! If the consumer of replaced dependency is singleton, it won't work
// cause the consumer singleton should be replaced too
c.Register<IBar, Bar>(Reuse.Singleton,
setup: Setup.With(asResolutionCall: true)); // required
var foo = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar>(foo.Bar);
c.Register<IBar, Bar2>(Reuse.Singleton,
setup: Setup.With(asResolutionCall: true), // required
ifAlreadyRegistered: IfAlreadyRegistered.Replace); // required
var foo2 = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar2>(foo2.Bar);
}
[Test]
public void Replace_singleton_dependency_with_UseInstance()
{
var c = new Container();
c.Register<Foo>();
//c.Register<Foo>(Reuse.Singleton); // !!! If the consumer of replaced dependency is singleton, it won't work
// cause the consumer singleton should be replaced too
c.UseInstance<IBar>(new Bar());
var foo = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar>(foo.Bar);
c.UseInstance<IBar>(new Bar2());
var foo2 = c.Resolve<Foo>();
Assert.IsInstanceOf<Bar2>(foo2.Bar);
}
I have some simple classes that need to be disposed a the end of the request.
For that end I call the Dispose method on those objects from the Application_EndRequest event in Global.asax.
This "works fine on my machine" but causes some problems on my production server where I get Cannot access a disposed object. This happens in some MVC helpers.
It seemed to me like Application_EndRequest is triggered at the end of the request. Is this not the case? Is there another event I should be using to dispose my objects?
Application pool issues - likely
I suspect that your disposable object isn't bound to request but rather app wide (it may be instantiated per request but it may be using some shared resources). As long as you're testing your application in development environment it seems to behave as expected but as soon as you put it in production you get issues. This indicates you may have problems with application pool.
IIS web application pool capabilities actually instantiate several HttpApplication instances for your application and they may all share common disposable resources. If that's the case with your disposable object and you're sharing it it may be that it isn't thread safe. The same would be true when you wouldn't wrap your shared resource usage inside thread safe operations.
That's why it may happen that while one request is in progress another one begins and the first one disposed the object while the second process still uses it.
More information is always helpful
If you'd explain the nature of your disposable object/resource and how you're using it in your application we could help you much better. But in the meantime, you could read my blog post that talks about application pools and handling them. It's not about disposable objects per se, but you may still find all the information very useful and helpful.
If you need some object disposable per-request to use inside your controllers, I would recommend you using controller's lifecycle handlers instead of using Application_BeginRequest and Application_EndRequest. See the following example.
The Controller:
public class BaseController : Controller
{
protected override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
this.HttpContext.Items["MyDisposableObject"] = new MyDisposableObject();
}
protected override void OnResultExecuted(ResultExecutedContext filterContext)
{
base.OnResultExecuted(filterContext);
if (this.HttpContext.Items.Contains("MyDisposableObject"))
{
var myDisposableObject =
this.HttpContext.Items["MyDisposableObject"] as IDisposable;
if (myDisposableObject != null)
{
myDisposableObject.Dispose();
}
}
}
}
The IDisposable object:
public sealed class MyDisposableObject : IDisposable
{
private bool disposed;
public void Dispose()
{
if (!this.disposed)
{
// Dispose all managed
// and unmanaged resources.
// Note disposing has been done.
this.disposed = true;
}
}
}
If the objects are scoped to controller level you can override the Dispose method of Controller to dispose those objects.
protected override void Dispose(bool disposing)
{
if(disposing)
{
// dispose the objects here
}
base.Dispose(disposing);
}
If you are using some DI framework (like Ninject) in your application you can delegate that job to them.
Instead of disposing the objects at the end of the request you can also try wrapping them in an using statement wherever you access by this way you make sure the object is disposed.
Background
I've read all kinds of blogs and documentation about nhibernate session management. My issue, is I need it for both winforms and webforms. That's right, I'm using the same data layer in both a winforms (windows .exe) and webforms (asp.net web) application. I've read a little about the unit of work pattern and is a good choice for winforms. Storing the nhibernate session in HttpRequest.Current.Items seems like a good way to go for web apps. But what about a combo deal? I have web apps, windows apps, and WCF services that all need to use the same nhibernate data layer. So back to my question...
I plan on using this design: NhibernateBestPractices in my web app like so:
private ISession ThreadSession {
get {
if (IsInWebContext()) {
return (ISession)HttpContext.Current.Items[SESSION_KEY];
}
else {
return (ISession)CallContext.GetData(SESSION_KEY);
}
}
set {
if (IsInWebContext()) {
HttpContext.Current.Items[SESSION_KEY] = value;
}
else {
CallContext.SetData(SESSION_KEY, value); // PROBLEM LINE HERE!!!
}
}
}
The Problem
The problem I am having when using this code in my windows app, is with the line
CallContext.SetData(SESSION_KEY, value);
If I understand CallContext() right, this will keep the session open the entire lifetime of my windows app because it stores the nhibernate session as part of the main applications thread. And I've heard all kinds of bad things about keeping an nhibernate session open for too long and I know by design, it's not mean to stay open very long. If all my assumptions are correct, then the above line of code is a no,no.
Given all this, I'd like to replace the above line with something that will destroy the nhibernate session more frequently in a windows app. Something similar to the lifetime of the HttpRequest. I don't want to leave it up to the windows client to know about the nhibernate session (or transaction) and when to open and close it. I'd like this to be triggered automagically.
The Question
So, where can I store the nhibernate session in a windows app that will allow me (ie. something besides the client) to automatically begin and end a transaction on a per database request (that is, whenever a client makes a call to the DB)?
** Update **
Here are 2 more links on how to implement the unit of work pattern
http://msdn.microsoft.com/en-us/magazine/dd882510.aspx
http://www.codeinsanity.com/2008/09/unit-of-work-pattern.html
Each of your apps can provide a common implementation of an interface like IUnitOfWorkStorage
public interface IUnitOfWorkStorage
{
void StoreUnitOfWork(IUnitOfWork uow);
}
IUnitOfWork can be a wrapper around the ISession which can look like this
public interface IUnitOfWork
{
void Begin();
void End();
}
Begin might open the session and start a transaction, while End would commit the transaction and close the session. So you can have 2 implementations of IUnitOfWorkStorage, one for the WebApp and one for the Windows App. The web app can use HttpContext.Current or something and your windows app can provide just a simple object store that is disposed at the end of your action which would End the UnitOfWork.
I ended up using the following code. The only "burden" it put on my app was the unit tests, and I'd rather muck up that code with session specific info that the production code. I kept the same code as mentioned in my question and then added this class to my unit test project:
namespace MyUnitTests
{
/// <summary>
/// Simulates the IHttpModule class but for windows apps.
/// There's no need to call BeginSession() and EndSession()
/// if you wrap the object in a "using" statement.
/// </summary>
public class NhibernateSessionModule : IDisposable
{
public NhibernateSessionModule()
{
NHibernateSessionManager.Instance.BeginTransaction();
}
public void BeginSession()
{
NHibernateSessionManager.Instance.BeginTransaction();
}
public void EndSession()
{
NHibernateSessionManager.Instance.CommitTransaction();
NHibernateSessionManager.Instance.CloseSession();
}
public void RollBackSession()
{
NHibernateSessionManager.Instance.RollbackTransaction();
}
#region Implementation of IDisposable
public void Dispose()
{
// if an Exception was NOT thrown then commit the transaction
if (Marshal.GetExceptionCode() == 0)
{
NHibernateSessionManager.Instance.CommitTransaction();
}
else
{
NHibernateSessionManager.Instance.RollbackTransaction();
}
CloseSession();
}
#endregion
}
}
And to use the above class you'd do something like this:
[Test]
public void GetByIdTest()
{
// begins an nhibernate session and transaction
using (new NhibernateSessionModule())
{
IMyCustomer myCust = MyCustomerDao.GetById(123);
Assert.IsNotNull(myCust);
} // ends the nhibernate transaction AND the session
}
Note: If you're using this method make to sure to not wrap your sessions in "using" statements when executing queries from your Dao classes like in this post. Because you're managing sessions yourself and keeping them open a littler longer that a single session per query, then you need to get rid of all the places you are closing the session and let the NhibernateSessionModule do that for you (web apps or windows apps).
I'm trying to get Quartz.net working by embedding into my .Net MVC2 application. I know this is not ideal, but I'm just trying to get it up and running before moving it over to a service. I can't get my jobs to fire off, but I think I'm configured correctly. In my Global.asax.cs:
protected void Application_Start()
{
Quartz.IScheduler scheduler = BuildQuartzScheduler();
...
}
And the method, taken straight from the tutorial:
private IScheduler BuildQuartzScheduler()
{
// construct a scheduler factory
ISchedulerFactory schedFact = new StdSchedulerFactory();
// get a scheduler
IScheduler sched = schedFact.GetScheduler();
sched.Start();
// construct job info
JobDetail jobDetail = new JobDetail("myJob", null, typeof(QuartzController));
// fire every hour
Trigger trigger = TriggerUtils.MakeMinutelyTrigger();
// start on the next even hour
trigger.StartTimeUtc = TriggerUtils.GetEvenMinuteDate(DateTime.UtcNow);
trigger.Name = "myTrigger";
sched.ScheduleJob(jobDetail, trigger);
return sched;
}
And the "controller:"
public class QuartzController : IJob
{
public QuartzController() {
}
public void Execute(JobExecutionContext context) {
throw new NotImplementedException();
}
}
Nothing ever gets fired. What's going on? I'm sure there must be a simple syntax mistake, but it is driving me crazy!
If Application_Start looks like that, then I reckon your scheduler variable is likely to be garbage collected as soon as that method finishes executing.
I'd store a reference to the scheduler as a static variable in your HttpApplication class. This way, the reference hangs around for the duration of the process. A guess, but worth a shot.
We are trying to remove the global.asax from our many web applications in favor of HttpModules that are in a common code base. This works really well for many application events such as BeginRequest and PostAuthentication, but there is no Application Start event exposed in the HttpModule.
I can think of a couple of smelly ways to overcome this deficit. For example, I can probably do this:
protected virtual void BeginRequest(object sender, EventArgs e)
{
Log.Debug("Entered BeginRequest...");
var app = HttpContext.Current.Application;
var hasBeenSet app["HasBeenExecuted"] == null ? false : true;
if(!hasBeenSet)
{
app.Lock();
// ... do app level code
app.Add("HasBeenExecuted", true);
app.Unlock();
}
// do regular begin request stuff ...
}
But this just doesn't smell well to me.
What is the best way to invoke some application begin logic without having a global.asax?
Just keep a static bool in the HttpModule:
private static bool _hasApplicationStarted = false;
private static object _locker = new object();
private void EnsureStarted()
{
if (_hasApplicationStarted) return;
lock (_locker)
{
if (_hasApplicationStarted) return;
// perform application startup here
_hasApplicationStarted = true;
}
}
Then have any method that needs the application to have started just call EnsureStarted.
HttpModules and HttpHandlers will execute on every single request, while the Global.asax App Start event is when the application starts, thus only once.
You could make a general global.asax which will load all assemblies with a specific interface, and then drop in the dll's you want executed for that specific application. Or even register them in your web.config, and have your general global.asax read the keys, and then load and execute the code you want.
I think this is better than putting app once code in a module and checking on a state variable.