0

We want to synchronize the data in our application with the data of an external service. (Such as accountancy software. This synchronization should be executed every night and when the customer wants to.

I am aware that long running threads don't belong in web applications and this synchronization should be executed within an external windows service. But the downside of this method is, that is becomes harder to deploy / maintain, since the application can be installed on the customer's webserver too.

Is it possible to completely integrate this synchronization with just the use of a class library project withing my solution, which will start up at the Application_Start event?

1 Answers1

2

Since your application is hosted on IIS, it's maintained by the application pool process. If you create additional module for your task, it will be running within context of the same process. You have to be sure this process is still working in the middle of the night, when application is not used, in order to perform the synchronization you want. You can use Quartz.NET to schedule your sync task.

But still, I think much better idea is to perform the synchronization from windows service. Service should communicate with the application for example by using database, where it logs its current activity. It gives you the possibility to monitor of the service state from the web by connecting to such database. I know service forces some additional administration effort, but it will be much more reliable and secure. You can also add service starting possibility from your web application (if pool process user has access rights to windows service) to overcome (or at least minimize) administration effort connecting with restarting your service after some failure.

I've written such functionality, so just to give you an overall look of what I mean by web monitoring of such external service, check the screen below. It can be written with the ajax support to achieve more responsiveness (pooling mechanism), which will be convenient for the end user.

enter image description here

jwaliszko
  • 16,942
  • 22
  • 92
  • 158
  • Thank you for your detailed answer, I guess i'm stuck to an external service then.. However you say you communicate through the db, is there a reason you don't communicate through a socket? And also, I come from PHP web dev, I have trouble understanding the life cycle of an asp.NET app. Is the application started once it is created in IIS and then runs forever until IIS shutdown / restarts? My main concern for not putting the sync in the app is because of the limited threads. Since the application can be used intensive by 10.000+ users, I don't want to sacrifice any performance for this sync. –  Dec 12 '12 at 18:03
  • Application hosted on IIS lives as long as process attached to the application pool defined within the IIS lives. By default, worker process will remain idle before it shuts down. A worker process is idle if it is not processing requests and no new requests are received (check Idle Time-out). You can also create custom http-ping kind of tool which will prevent worker process from changing into idle state. In addition and by default IIS recycles application pool after some time (check Regular Time Interval). So basically as you can see, the application is supposed to be restarted periodically. – jwaliszko Dec 13 '12 at 15:52
  • Answering the second question, why I used db instead of socket for communication ? Because I already had database prepared, and I needed to persist some synchronization settings set up by user so it was natural choice for me in this particular case. I have no objections using MSMQ, sockets or WCF. It depends of what you need. Check for example this: http://stackoverflow.com/questions/84855/what-is-the-best-choice-for-net-inter-process-communication or this: http://stackoverflow.com/questions/1262795/communication-between-two-separate-applications topics about inter-process communication (IPC). – jwaliszko Dec 13 '12 at 16:02