Multithreading in ASP.NET app???

Discussion in 'ASP .Net' started by JV, Mar 13, 2006.

  1. JV

    JV Guest

    My ASP.NET application needs to accept data from a post and return quickly.
    I've added a worker thread to wake up and save data asynchronously after the
    data is received. But, it appears to me that IIS kills the process and
    thus the worker thread right after my main ASP.NET thread returns (anyone
    know for certain?).

    Do you know of a design pattern to accomplish this?
    JV, Mar 13, 2006
    #1
    1. Advertising

  2. JV,

    You have to figure out for what reason ASP.NET is killing the process.
    ASP.NET does have application recycling if the app goes down, and sometimes,
    if memory consumption is too high, it will recycle the process.

    What I would recommend is writing a service that will perform this
    operation for you, then using a technology like MSMQ (through
    System.Messaging) to send a message to the service, which will then handle
    the updating of the data.

    Hope this helps.


    --
    - Nicholas Paldino [.NET/C# MVP]
    -

    "JV" <> wrote in message
    news:...
    > My ASP.NET application needs to accept data from a post and return
    > quickly. I've added a worker thread to wake up and save data
    > asynchronously after the data is received. But, it appears to me that
    > IIS kills the process and thus the worker thread right after my main
    > ASP.NET thread returns (anyone know for certain?).
    >
    > Do you know of a design pattern to accomplish this?
    >
    Nicholas Paldino [.NET/C# MVP], Mar 13, 2006
    #2
    1. Advertising

  3. Hi,

    Check this out...

    /Oscar

    //Buisness layer...gets called from an ASP.NET web page...
    public bool InitAsyncOperation(string someData)
    {
    try
    {
    //Access layer
    Access access = Access.GetInstance(CurrentUser);

    if(access.IsRunning)
    {
    return false;
    }
    else
    {
    //First we do some sync operation...
    Wrapper wrapper = access.Validate(someData);

    //Then we kick of the async...
    MyDelegate d = new MyDelegate(<Another method...that performs the async
    operation...>);
    AsyncHelper.Execute(d, wrapper);
    }
    }
    catch(Exception ex)
    {
    if(ExceptionPolicy.HandleException(ex, CONTROLLER_EXCEPTION_POLICY))
    throw;
    }

    return true;
    }




    ///Class AsyncHelper
    using System;
    using System.Reflection;
    using System.Threading;

    namespace <SomeCompany>.<SomeApp>.Util
    {
    /// <summary>
    /// Starting with the 1.1 release of the .NET Framework, the SDK docs
    /// now carry a caution that mandates calling EndInvoke on delegates
    /// you've called BeginInvoke on in order to avoid potential leaks.
    /// This means you cannot simply "fire-and-forget" a call to BeginInvoke
    /// when spawning a new worker thread from the thread pool without the
    risk
    /// of creating a memory leak.
    ///
    /// The usage model is that instead of calling BeginInvoke against a
    delegate,
    /// you would instead call AsyncHelper.Execute, passing that delegate and
    it's parameters as input.
    /// See: http://staff.develop.com/woodring for further information.
    /// </summary>
    /// <example>
    /// delegate void CalcAndDisplaySumDelegate( int a, int b );
    /// CalcAndDisplaySumDelegate d = new
    CalcAndDisplaySumDelegate(someCalc.Add);
    /// AsyncHelper.Execute(d, 2, 3);
    /// </example>
    public class AsyncHelper
    {
    private static WaitCallback callback = new
    WaitCallback(DynamicInvokeShim);

    /// <summary>
    /// Takes a delegate and a list of arguments. Performs asynchronous
    invocation of the
    /// target(the Class.Method the delegates points to..).
    /// </summary>
    /// <param name="d"></param>
    /// <param name="args"></param>
    /// <Author>Oscar Thornell</Author>
    public static void Execute(Delegate d, params object[] args)
    {
    ThreadPool.QueueUserWorkItem(callback, new TargetInfo(d, args));
    }

    private static void DynamicInvokeShim(object obj)
    {
    TargetInfo targetInfo = (TargetInfo)obj;
    targetInfo.Target.DynamicInvoke(targetInfo.Args);
    }

    class TargetInfo
    {
    internal readonly Delegate Target;
    internal readonly object[] Args;

    internal TargetInfo(Delegate d, object[] args)
    {
    Target = d;
    Args = args;
    }
    }
    }
    }



    "JV" <> wrote in message
    news:...
    > My ASP.NET application needs to accept data from a post and return
    > quickly. I've added a worker thread to wake up and save data
    > asynchronously after the data is received. But, it appears to me that
    > IIS kills the process and thus the worker thread right after my main
    > ASP.NET thread returns (anyone know for certain?).
    >
    > Do you know of a design pattern to accomplish this?
    >
    Oscar Thornell, Mar 13, 2006
    #3
  4. As you observed, you are not gaining much with multithreading in Asp.Net.

    You can make a Windows service that will pick up requests made by the
    Asp.Net application. The requests can be passed on in a number of ways. Two
    most common ones are via a database and via files.

    Eliyahu

    "JV" <> wrote in message
    news:...
    > My ASP.NET application needs to accept data from a post and return
    > quickly. I've added a worker thread to wake up and save data
    > asynchronously after the data is received. But, it appears to me that
    > IIS kills the process and thus the worker thread right after my main
    > ASP.NET thread returns (anyone know for certain?).
    >
    > Do you know of a design pattern to accomplish this?
    >
    Eliyahu Goldin, Mar 13, 2006
    #4
  5. I wouldn't recommend using a database or files for notifications to the
    service. That would require you to poll for the result, which on a general
    level, is not too efficient.


    --
    - Nicholas Paldino [.NET/C# MVP]
    -

    "Eliyahu Goldin" <> wrote in message
    news:OWN%...
    > As you observed, you are not gaining much with multithreading in Asp.Net.
    >
    > You can make a Windows service that will pick up requests made by the
    > Asp.Net application. The requests can be passed on in a number of ways.
    > Two most common ones are via a database and via files.
    >
    > Eliyahu
    >
    > "JV" <> wrote in message
    > news:...
    >> My ASP.NET application needs to accept data from a post and return
    >> quickly. I've added a worker thread to wake up and save data
    >> asynchronously after the data is received. But, it appears to me that
    >> IIS kills the process and thus the worker thread right after my main
    >> ASP.NET thread returns (anyone know for certain?).
    >>
    >> Do you know of a design pattern to accomplish this?
    >>

    >
    >
    Nicholas Paldino [.NET/C# MVP], Mar 13, 2006
    #5
  6. System.IO.FileSystemWatcher is a nice class that takes care of notification
    in case of files.

    Eliyahu

    "Nicholas Paldino [.NET/C# MVP]" <> wrote in
    message news:...
    > I wouldn't recommend using a database or files for notifications to the
    > service. That would require you to poll for the result, which on a
    > general level, is not too efficient.
    >
    >
    > --
    > - Nicholas Paldino [.NET/C# MVP]
    > -
    >
    > "Eliyahu Goldin" <> wrote in message
    > news:OWN%...
    >> As you observed, you are not gaining much with multithreading in Asp.Net.
    >>
    >> You can make a Windows service that will pick up requests made by the
    >> Asp.Net application. The requests can be passed on in a number of ways.
    >> Two most common ones are via a database and via files.
    >>
    >> Eliyahu
    >>
    >> "JV" <> wrote in message
    >> news:...
    >>> My ASP.NET application needs to accept data from a post and return
    >>> quickly. I've added a worker thread to wake up and save data
    >>> asynchronously after the data is received. But, it appears to me that
    >>> IIS kills the process and thus the worker thread right after my main
    >>> ASP.NET thread returns (anyone know for certain?).
    >>>
    >>> Do you know of a design pattern to accomplish this?
    >>>

    >>
    >>

    >
    >
    Eliyahu Goldin, Mar 13, 2006
    #6
  7. Eliyahu Goldin wrote:
    > System.IO.FileSystemWatcher is a nice class that takes care of notification
    > in case of files.


    Not reliably, in my experience. I don't know *exactly* what goes wrong,
    but often FileSystemWatcher can end up missing events, or waiting a
    while and then delivering batches etc. I'm not the only one to have
    noticed this. I still use FSW, but only in conjunction with something
    which manually polls in case something goes wrong. It's all a bit of a
    hack :(

    Jon
    Jon Skeet [C# MVP], Mar 13, 2006
    #7
  8. JV

    JV Guest

    I've only skimmed over your code thus far, but it appears you are spawning a
    thread from the threadpool for each ASP.NET request? If I'm correct about
    that, that would become a scalability issue.
    My goal is to have a single worker thread that manages the dataset and
    multiple requests putting/getting data. Wish I could have just used MSSQL
    for this.


    "Oscar Thornell" <> wrote in message
    news:...
    > Hi,
    >
    > Check this out...
    >
    > /Oscar
    >
    > //Buisness layer...gets called from an ASP.NET web page...
    > public bool InitAsyncOperation(string someData)
    > {
    > try
    > {
    > //Access layer
    > Access access = Access.GetInstance(CurrentUser);
    >
    > if(access.IsRunning)
    > {
    > return false;
    > }
    > else
    > {
    > //First we do some sync operation...
    > Wrapper wrapper = access.Validate(someData);
    >
    > //Then we kick of the async...
    > MyDelegate d = new MyDelegate(<Another method...that performs the
    > async operation...>);
    > AsyncHelper.Execute(d, wrapper);
    > }
    > }
    > catch(Exception ex)
    > {
    > if(ExceptionPolicy.HandleException(ex, CONTROLLER_EXCEPTION_POLICY))
    > throw;
    > }
    >
    > return true;
    > }
    >
    >
    >
    >
    > ///Class AsyncHelper
    > using System;
    > using System.Reflection;
    > using System.Threading;
    >
    > namespace <SomeCompany>.<SomeApp>.Util
    > {
    > /// <summary>
    > /// Starting with the 1.1 release of the .NET Framework, the SDK docs
    > /// now carry a caution that mandates calling EndInvoke on delegates
    > /// you've called BeginInvoke on in order to avoid potential leaks.
    > /// This means you cannot simply "fire-and-forget" a call to
    > BeginInvoke
    > /// when spawning a new worker thread from the thread pool without the
    > risk
    > /// of creating a memory leak.
    > ///
    > /// The usage model is that instead of calling BeginInvoke against a
    > delegate,
    > /// you would instead call AsyncHelper.Execute, passing that delegate and
    > it's parameters as input.
    > /// See: http://staff.develop.com/woodring for further information.
    > /// </summary>
    > /// <example>
    > /// delegate void CalcAndDisplaySumDelegate( int a, int b );
    > /// CalcAndDisplaySumDelegate d = new
    > CalcAndDisplaySumDelegate(someCalc.Add);
    > /// AsyncHelper.Execute(d, 2, 3);
    > /// </example>
    > public class AsyncHelper
    > {
    > private static WaitCallback callback = new
    > WaitCallback(DynamicInvokeShim);
    >
    > /// <summary>
    > /// Takes a delegate and a list of arguments. Performs asynchronous
    > invocation of the
    > /// target(the Class.Method the delegates points to..).
    > /// </summary>
    > /// <param name="d"></param>
    > /// <param name="args"></param>
    > /// <Author>Oscar Thornell</Author>
    > public static void Execute(Delegate d, params object[] args)
    > {
    > ThreadPool.QueueUserWorkItem(callback, new TargetInfo(d, args));
    > }
    >
    > private static void DynamicInvokeShim(object obj)
    > {
    > TargetInfo targetInfo = (TargetInfo)obj;
    > targetInfo.Target.DynamicInvoke(targetInfo.Args);
    > }
    >
    > class TargetInfo
    > {
    > internal readonly Delegate Target;
    > internal readonly object[] Args;
    >
    > internal TargetInfo(Delegate d, object[] args)
    > {
    > Target = d;
    > Args = args;
    > }
    > }
    > }
    > }
    >
    >
    >
    > "JV" <> wrote in message
    > news:...
    >> My ASP.NET application needs to accept data from a post and return
    >> quickly. I've added a worker thread to wake up and save data
    >> asynchronously after the data is received. But, it appears to me that
    >> IIS kills the process and thus the worker thread right after my main
    >> ASP.NET thread returns (anyone know for certain?).
    >>
    >> Do you know of a design pattern to accomplish this?
    >>

    >
    >
    JV, Mar 13, 2006
    #8
  9. Hi,


    "JV" <> wrote in message
    news:...
    > My ASP.NET application needs to accept data from a post and return
    > quickly. I've added a worker thread to wake up and save data


    TO wake up ?
    How r u storing the thread reference? in Application ?
    How r u running it?
    Show some code for more details.

    What if you create the thread at each request? This allow you to create one
    thread per request and not having to worry about concurrency, the drawback
    is that you may create lots of threads depending of how busy is your web
    site.



    cheers,

    --
    Ignacio Machin,
    ignacio.machin AT dot.state.fl.us
    Florida Department Of Transportation
    Ignacio Machin \( .NET/ C# MVP \), Mar 13, 2006
    #9
  10. JV

    JV Guest

    Thanks for the reply!

    Actually I was storing the reference to the object in Session, but I could
    just as easily move it to Application. That would actually make more sense.

    I am trying to avoid creating a thread per request. That sort of defeats
    the purpose of returning quickly for scalability.



    "Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
    in message news:...
    > Hi,
    >
    >
    > "JV" <> wrote in message
    > news:...
    >> My ASP.NET application needs to accept data from a post and return
    >> quickly. I've added a worker thread to wake up and save data

    >
    > TO wake up ?
    > How r u storing the thread reference? in Application ?
    > How r u running it?
    > Show some code for more details.
    >
    > What if you create the thread at each request? This allow you to create
    > one thread per request and not having to worry about concurrency, the
    > drawback is that you may create lots of threads depending of how busy is
    > your web site.
    >
    >
    >
    > cheers,
    >
    > --
    > Ignacio Machin,
    > ignacio.machin AT dot.state.fl.us
    > Florida Department Of Transportation
    >
    >
    >
    JV, Mar 13, 2006
    #10
  11. JV

    Russell Guest

    I create a worker thread from within an ASPX page as follows (code is
    actually in a server control used in the page, so it is defined in its
    own named assembly):

    System.Threading.ThreadStart ts = new
    System.Threading.ThreadStart(ProcessCleanupFiles);
    System.Threading.Thread thread = new System.Threading.Thread(ts);
    thread.Start();

    The page returns in a timely fashion and the thread survives to do
    cleanup. For testing I tried putting a 30 second sleep into
    ProcessCleanupFiles to test that a) it did not slow my page return b)
    it does execute after the delay. I have not explicitly tested for
    memory leaks but based on my understanding, "thread" should get cleaned
    up sometime after both the invoking method and ProcessCleanupFiles
    complete.
    Russell, Mar 13, 2006
    #11
  12. JV,

    What does your mainthread do in the meantime.

    With the information you give now, do I not see any sense for
    multithreading.

    Moreover the only thing you achieve is that your processing time will be
    take more time.

    Just my thought,

    Cor


    "JV" <> schreef in bericht
    news:...
    > My ASP.NET application needs to accept data from a post and return
    > quickly. I've added a worker thread to wake up and save data
    > asynchronously after the data is received. But, it appears to me that
    > IIS kills the process and thus the worker thread right after my main
    > ASP.NET thread returns (anyone know for certain?).
    >
    > Do you know of a design pattern to accomplish this?
    >
    Cor Ligthert [MVP], Mar 13, 2006
    #12
  13. Hi,

    How much time the DB operation takes?

    Do not store it in application, if you do so ALL the sessions will try to
    use it.

    If the DB operation takes a long time using MSQS would be a good suggestion


    --
    Ignacio Machin,
    ignacio.machin AT dot.state.fl.us
    Florida Department Of Transportation


    "JV" <> wrote in message
    news:...
    > Thanks for the reply!
    >
    > Actually I was storing the reference to the object in Session, but I could
    > just as easily move it to Application. That would actually make more
    > sense.
    >
    > I am trying to avoid creating a thread per request. That sort of defeats
    > the purpose of returning quickly for scalability.
    >
    >
    >
    > "Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
    > wrote in message news:...
    >> Hi,
    >>
    >>
    >> "JV" <> wrote in message
    >> news:...
    >>> My ASP.NET application needs to accept data from a post and return
    >>> quickly. I've added a worker thread to wake up and save data

    >>
    >> TO wake up ?
    >> How r u storing the thread reference? in Application ?
    >> How r u running it?
    >> Show some code for more details.
    >>
    >> What if you create the thread at each request? This allow you to create
    >> one thread per request and not having to worry about concurrency, the
    >> drawback is that you may create lots of threads depending of how busy is
    >> your web site.
    >>
    >>
    >>
    >> cheers,
    >>
    >> --
    >> Ignacio Machin,
    >> ignacio.machin AT dot.state.fl.us
    >> Florida Department Of Transportation
    >>
    >>
    >>

    >
    >
    Ignacio Machin \( .NET/ C# MVP \), Mar 13, 2006
    #13
  14. Hi,

    "Jon Skeet [C# MVP]" <> wrote in message
    news:...
    > Eliyahu Goldin wrote:
    >> System.IO.FileSystemWatcher is a nice class that takes care of
    >> notification
    >> in case of files.

    >
    > Not reliably, in my experience. I don't know *exactly* what goes wrong,
    > but often FileSystemWatcher can end up missing events, or waiting a
    > while and then delivering batches etc. I'm not the only one to have
    > noticed this. I still use FSW, but only in conjunction with something
    > which manually polls in case something goes wrong. It's all a bit of a
    > hack :(


    Totally agree with you in this, not only you may lose events ( not my case
    so far) but you may get duplicated events for a single user action. I use a
    lock while processing and deleting(or moving) files as a workaround.

    Anyway files are not the best option for the OP's problem



    --
    Ignacio Machin,
    ignacio.machin AT dot.state.fl.us
    Florida Department Of Transportation
    Ignacio Machin \( .NET/ C# MVP \), Mar 13, 2006
    #14
  15. JV,
    I see no reason why you couldn't have a class in Application State that
    would hold a DataSet whose table to which you would add your post data.
    Whenever a new row is added (or when "x" number of rows had been added) the
    class would perform an DataAdapter Update to your Sql server and clear out
    the datatable to wait for more posts.
    Peter

    --
    Co-founder, Eggheadcafe.com developer portal:
    http://www.eggheadcafe.com
    UnBlog:
    http://petesbloggerama.blogspot.com




    "JV" wrote:

    > My ASP.NET application needs to accept data from a post and return quickly.
    > I've added a worker thread to wake up and save data asynchronously after the
    > data is received. But, it appears to me that IIS kills the process and
    > thus the worker thread right after my main ASP.NET thread returns (anyone
    > know for certain?).
    >
    > Do you know of a design pattern to accomplish this?
    >
    >
    >
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=, Mar 13, 2006
    #15
  16. JV

    JV Guest

    The goal is to allow the main thread to append some data or request some
    data from a dataset. But persistence would be managed on another thread so
    as not to slow up the ASP.NET application unless necessary.

    Idea was to use a ManualResetEvent to let the worker thread know there was
    some work to do and a Mutex to serialize access to the data. Thus, if many
    requests were coming in close together, the worker thread might have to wait
    awhile to do persistence, but the ASP.NET application could carry on with
    the in-memory data.

    Why would you say that this increases processing time? Maybe in total, but
    performance for the ASP.NET application should be increased, which is the
    key.


    "Cor Ligthert [MVP]" <> wrote in message
    news:...
    > JV,
    >
    > What does your mainthread do in the meantime.
    >
    > With the information you give now, do I not see any sense for
    > multithreading.
    >
    > Moreover the only thing you achieve is that your processing time will be
    > take more time.
    >
    > Just my thought,
    >
    > Cor
    >
    >
    > "JV" <> schreef in bericht
    > news:...
    >> My ASP.NET application needs to accept data from a post and return
    >> quickly. I've added a worker thread to wake up and save data
    >> asynchronously after the data is received. But, it appears to me that
    >> IIS kills the process and thus the worker thread right after my main
    >> ASP.NET thread returns (anyone know for certain?).
    >>
    >> Do you know of a design pattern to accomplish this?
    >>

    >
    >
    JV, Mar 13, 2006
    #16
  17. JV

    John Bailo Guest

    The problem is your code is finishing before the worker thread
    completes. You need a method to evaluate that the worker thread has
    completed before allow the ASP.NET application to end.

    I use this pattern

    //put my process on a thread
    results.Add(this.as400maketable(s,tableString));

    //the threaded method
    private IAsyncResult as400maketable(string line, string tablename)
    {
    AsyncCallback delCB = new AsyncCallback(this.AsyncCB);
    IAsyncResult ar = null;
    //does a DB2 database insert
    ar = as400.BegininsertData(line, tablename, delCB, null);
    return ar;
    }

    //callback method
    void AsyncCB(IAsyncResult ar)
    {
    as400.EndinsertPolarData(ar);
    }

    //Then back in my main thread I check to see all my threads are done:
    foreach(IAsyncResult ar in results)
    ar.AsyncWaitHandle.WaitOne();


    JV wrote:
    > My ASP.NET application needs to accept data from a post and return quickly.
    > I've added a worker thread to wake up and save data asynchronously after the
    > data is received. But, it appears to me that IIS kills the process and
    > thus the worker thread right after my main ASP.NET thread returns (anyone
    > know for certain?).
    >
    > Do you know of a design pattern to accomplish this?
    >
    >
    John Bailo, Mar 13, 2006
    #17
  18. John Bailo <> wrote:
    > The problem is your code is finishing before the worker thread
    > completes. You need a method to evaluate that the worker thread has
    > completed before allow the ASP.NET application to end.


    No, the whole point is (as I understand it) to make the web page return
    quickly, queueing the data for insert later as it will take some time.
    Unfortunately the way that IIS recycles AppDomains etc can make this
    somewhat flaky. Instead of starting separate threads and assuming
    they'll continue, the OP will need to queue the data in a more robust
    way (eg to the file system or MSMQ) before returning, possibly
    processing it in a different process altogether.

    --
    Jon Skeet - <>
    http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
    If replying to the group, please do not mail me too
    Jon Skeet [C# MVP], Mar 14, 2006
    #18
  19. JV,

    See this

    Page load
    Start workerthread
    Do some things in the mainthread
    Let main thread sleep in a processing loop to see if the workerthread is
    ready and if ready go on
    (otherwise the page is sent back and this page goes out of scope)
    Sent page back

    What is your advantage in this, that really should in my opinion really be
    hug if it is in an ASPNET application more than the processing needed for
    the threads and the checking of those are ready(it is not your code however
    what is needed)?

    And the processor is of course not only used by this client.

    I hope this helps,

    Cor

    "JV" <> schreef in bericht
    news:...
    > The goal is to allow the main thread to append some data or request some
    > data from a dataset. But persistence would be managed on another thread
    > so as not to slow up the ASP.NET application unless necessary.
    >
    > Idea was to use a ManualResetEvent to let the worker thread know there was
    > some work to do and a Mutex to serialize access to the data. Thus, if
    > many requests were coming in close together, the worker thread might have
    > to wait awhile to do persistence, but the ASP.NET application could carry
    > on with the in-memory data.
    >
    > Why would you say that this increases processing time? Maybe in total,
    > but performance for the ASP.NET application should be increased, which is
    > the key.
    >
    >
    > "Cor Ligthert [MVP]" <> wrote in message
    > news:...
    >> JV,
    >>
    >> What does your mainthread do in the meantime.
    >>
    >> With the information you give now, do I not see any sense for
    >> multithreading.
    >>
    >> Moreover the only thing you achieve is that your processing time will be
    >> take more time.
    >>
    >> Just my thought,
    >>
    >> Cor
    >>
    >>
    >> "JV" <> schreef in bericht
    >> news:...
    >>> My ASP.NET application needs to accept data from a post and return
    >>> quickly. I've added a worker thread to wake up and save data
    >>> asynchronously after the data is received. But, it appears to me that
    >>> IIS kills the process and thus the worker thread right after my main
    >>> ASP.NET thread returns (anyone know for certain?).
    >>>
    >>> Do you know of a design pattern to accomplish this?
    >>>

    >>
    >>

    >
    >
    Cor Ligthert [MVP], Mar 14, 2006
    #19
  20. Thats correct! It works in my solution, since the use case is to start a
    batch like process that doesn´t happen to often...and let the user proceed
    to other tasks..
    I think that you should try using the threadpool and test the performance...

    /Oscar

    "JV" <> wrote in message
    news:...
    > I've only skimmed over your code thus far, but it appears you are spawning
    > a thread from the threadpool for each ASP.NET request? If I'm correct
    > about that, that would become a scalability issue.
    > My goal is to have a single worker thread that manages the dataset and
    > multiple requests putting/getting data. Wish I could have just used
    > MSSQL for this.
    >
    >
    > "Oscar Thornell" <> wrote in message
    > news:...
    >> Hi,
    >>
    >> Check this out...
    >>
    >> /Oscar
    >>
    >> //Buisness layer...gets called from an ASP.NET web page...
    >> public bool InitAsyncOperation(string someData)
    >> {
    >> try
    >> {
    >> //Access layer
    >> Access access = Access.GetInstance(CurrentUser);
    >>
    >> if(access.IsRunning)
    >> {
    >> return false;
    >> }
    >> else
    >> {
    >> //First we do some sync operation...
    >> Wrapper wrapper = access.Validate(someData);
    >>
    >> //Then we kick of the async...
    >> MyDelegate d = new MyDelegate(<Another method...that performs the
    >> async operation...>);
    >> AsyncHelper.Execute(d, wrapper);
    >> }
    >> }
    >> catch(Exception ex)
    >> {
    >> if(ExceptionPolicy.HandleException(ex, CONTROLLER_EXCEPTION_POLICY))
    >> throw;
    >> }
    >>
    >> return true;
    >> }
    >>
    >>
    >>
    >>
    >> ///Class AsyncHelper
    >> using System;
    >> using System.Reflection;
    >> using System.Threading;
    >>
    >> namespace <SomeCompany>.<SomeApp>.Util
    >> {
    >> /// <summary>
    >> /// Starting with the 1.1 release of the .NET Framework, the SDK docs
    >> /// now carry a caution that mandates calling EndInvoke on delegates
    >> /// you've called BeginInvoke on in order to avoid potential leaks.
    >> /// This means you cannot simply "fire-and-forget" a call to
    >> BeginInvoke
    >> /// when spawning a new worker thread from the thread pool without the
    >> risk
    >> /// of creating a memory leak.
    >> ///
    >> /// The usage model is that instead of calling BeginInvoke against a
    >> delegate,
    >> /// you would instead call AsyncHelper.Execute, passing that delegate and
    >> it's parameters as input.
    >> /// See: http://staff.develop.com/woodring for further information.
    >> /// </summary>
    >> /// <example>
    >> /// delegate void CalcAndDisplaySumDelegate( int a, int b );
    >> /// CalcAndDisplaySumDelegate d = new
    >> CalcAndDisplaySumDelegate(someCalc.Add);
    >> /// AsyncHelper.Execute(d, 2, 3);
    >> /// </example>
    >> public class AsyncHelper
    >> {
    >> private static WaitCallback callback = new
    >> WaitCallback(DynamicInvokeShim);
    >>
    >> /// <summary>
    >> /// Takes a delegate and a list of arguments. Performs asynchronous
    >> invocation of the
    >> /// target(the Class.Method the delegates points to..).
    >> /// </summary>
    >> /// <param name="d"></param>
    >> /// <param name="args"></param>
    >> /// <Author>Oscar Thornell</Author>
    >> public static void Execute(Delegate d, params object[] args)
    >> {
    >> ThreadPool.QueueUserWorkItem(callback, new TargetInfo(d, args));
    >> }
    >>
    >> private static void DynamicInvokeShim(object obj)
    >> {
    >> TargetInfo targetInfo = (TargetInfo)obj;
    >> targetInfo.Target.DynamicInvoke(targetInfo.Args);
    >> }
    >>
    >> class TargetInfo
    >> {
    >> internal readonly Delegate Target;
    >> internal readonly object[] Args;
    >>
    >> internal TargetInfo(Delegate d, object[] args)
    >> {
    >> Target = d;
    >> Args = args;
    >> }
    >> }
    >> }
    >> }
    >>
    >>
    >>
    >> "JV" <> wrote in message
    >> news:...
    >>> My ASP.NET application needs to accept data from a post and return
    >>> quickly. I've added a worker thread to wake up and save data
    >>> asynchronously after the data is received. But, it appears to me that
    >>> IIS kills the process and thus the worker thread right after my main
    >>> ASP.NET thread returns (anyone know for certain?).
    >>>
    >>> Do you know of a design pattern to accomplish this?
    >>>

    >>
    >>

    >
    >
    Oscar Thornell, Mar 14, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Leon
    Replies:
    5
    Views:
    477
    Alvin Bruney [MVP]
    Apr 11, 2004
  2. Alvin Bruney [MVP]

    Re: Multithreading in asp.net application

    Alvin Bruney [MVP], Apr 11, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    536
    Alvin Bruney [MVP]
    Apr 11, 2004
  3. who be dat?

    Safe multithreading in ASP.Net

    who be dat?, Aug 6, 2004, in forum: ASP .Net
    Replies:
    16
    Views:
    944
    Joe Fallon
    Aug 7, 2004
  4. robbo81gee

    Multithreading in asp.net web app

    robbo81gee, Sep 24, 2009, in forum: .NET
    Replies:
    0
    Views:
    373
    robbo81gee
    Sep 24, 2009
  5. Headless Rider

    Control asp.net app from other asp.net app

    Headless Rider, Aug 18, 2003, in forum: ASP .Net Security
    Replies:
    0
    Views:
    89
    Headless Rider
    Aug 18, 2003
Loading...

Share This Page