Problem Passing DataSet through Async Proxy

Discussion in 'ASP .Net Web Services' started by Dustin, Dec 23, 2004.

  1. Dustin

    Dustin Guest

    All,

    I have a windows service that passes a dataset to a webmethod. The
    webmethod then puts the dataset into a private message queue. I
    created the proxy for the webmethod in visual studio, by adding a
    reference to the webmethod, not using wsdl.exe manually.

    Initially I flushed out the code calling the synchronous version of the
    generated proxy for the webmethod. This worked fine and I was able to
    see the datasets transferred properly to the private queue via the
    webmethod.

    Subsequently I changed the implementation to use the asynchronous
    version of the webmethod's proxy. Everything seemed to be working
    fine, datasets were arriving in the private queue and callbacks firing
    fine.

    Today I implemented the queue drainer and found that there were no rows
    in the datasets that I was pulling out of the private queue. After
    awhile I traced it back to the fact that there were no rows in the
    dataset received by the webmethod. It turns out that if I revert to
    calling the synchronous version of the proxy, the dataset is properly
    transferred (with rows) to the webmethod and subsequently to the
    private queue.

    I have attempted to regenerate the proxy and there is no change in
    behavior.

    This seems quite odd. Does anyone have reference indicating that a
    difference exists between the serialization performed on datasets in
    synchronous calls vs. asynchronous calls?

    Thanks in advance,

    Dustin
    Newbrook Solutions
    www.newbrooksolutions.com
     
    Dustin, Dec 23, 2004
    #1
    1. Advertising

  2. Dustin

    Dan Rogers Guest

    Hi Dustin,

    I think I saw ar related thread a while back. There are apparently
    threading access issues that are intrinsic to data sets - but this is just
    anecdotal based on threads I saw discussing this at an earlier time. I
    would suspect that the second thread that is servicing the background call
    is unable to read the data from the dataset that was created by the
    foreground thread.

    As a remedy, try serializing the dataset to XML, and then passing the
    XMLDocument to the web method in your proxy.

    I hope this helps

    Dan Rogers
    Microsoft Corporation
    --------------------
    >From: "Dustin" <>
    >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    >Subject: Problem Passing DataSet through Async Proxy
    >Date: 22 Dec 2004 20:23:40 -0800
    >Organization: http://groups.google.com
    >Lines: 38
    >Message-ID: <>
    >NNTP-Posting-Host: 68.235.175.182
    >Mime-Version: 1.0
    >Content-Type: text/plain; charset="iso-8859-1"
    >X-Trace: posting.google.com 1103775825 7642 127.0.0.1 (23 Dec 2004

    04:23:45 GMT)
    >X-Complaints-To:
    >NNTP-Posting-Date: Thu, 23 Dec 2004 04:23:45 +0000 (UTC)
    >User-Agent: G2/0.2
    >Complaints-To:
    >Injection-Info: z14g2000cwz.googlegroups.com; posting-host=68.235.175.182;
    > posting-account=RQCAeA0AAAD3LqKwWkK7dT5s5xKt50OA
    >Path:

    cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!tornado.fastwebnet.it!tiscali!new
    sfeed1.ip.tiscali.net!news.glorb.com!postnews.google.com!z14g2000cwz.googleg
    roups.com!not-for-mail
    >Xref: cpmsftngxa10.phx.gbl

    microsoft.public.dotnet.framework.aspnet.webservices:27371
    >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    >
    >All,
    >
    >I have a windows service that passes a dataset to a webmethod. The
    >webmethod then puts the dataset into a private message queue. I
    >created the proxy for the webmethod in visual studio, by adding a
    >reference to the webmethod, not using wsdl.exe manually.
    >
    >Initially I flushed out the code calling the synchronous version of the
    >generated proxy for the webmethod. This worked fine and I was able to
    >see the datasets transferred properly to the private queue via the
    >webmethod.
    >
    >Subsequently I changed the implementation to use the asynchronous
    >version of the webmethod's proxy. Everything seemed to be working
    >fine, datasets were arriving in the private queue and callbacks firing
    >fine.
    >
    >Today I implemented the queue drainer and found that there were no rows
    >in the datasets that I was pulling out of the private queue. After
    >awhile I traced it back to the fact that there were no rows in the
    >dataset received by the webmethod. It turns out that if I revert to
    >calling the synchronous version of the proxy, the dataset is properly
    >transferred (with rows) to the webmethod and subsequently to the
    >private queue.
    >
    >I have attempted to regenerate the proxy and there is no change in
    >behavior.
    >
    >This seems quite odd. Does anyone have reference indicating that a
    >difference exists between the serialization performed on datasets in
    >synchronous calls vs. asynchronous calls?
    >
    >Thanks in advance,
    >
    >Dustin
    >Newbrook Solutions
    >www.newbrooksolutions.com
    >
    >
     
    Dan Rogers, Jan 4, 2005
    #2
    1. Advertising

  3. Dustin

    Dustin Guest

    Dan Rogers wrote:
    > Hi Dustin,
    >
    > I think I saw ar related thread a while back. There are apparently
    > threading access issues that are intrinsic to data sets - but this is

    just
    > anecdotal based on threads I saw discussing this at an earlier time.

    I
    > would suspect that the second thread that is servicing the background

    call
    > is unable to read the data from the dataset that was created by the
    > foreground thread.
    >
    > As a remedy, try serializing the dataset to XML, and then passing the


    > XMLDocument to the web method in your proxy.
    >
    > I hope this helps
    >
    > Dan Rogers
    > Microsoft Corporation
    > --------------------
    > >From: "Dustin" <>
    > >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
    > >Subject: Problem Passing DataSet through Async Proxy
    > >Date: 22 Dec 2004 20:23:40 -0800
    > >Organization: http://groups.google.com
    > >Lines: 38
    > >Message-ID: <>
    > >NNTP-Posting-Host: 68.235.175.182
    > >Mime-Version: 1.0
    > >Content-Type: text/plain; charset="iso-8859-1"
    > >X-Trace: posting.google.com 1103775825 7642 127.0.0.1 (23 Dec 2004

    > 04:23:45 GMT)
    > >X-Complaints-To:
    > >NNTP-Posting-Date: Thu, 23 Dec 2004 04:23:45 +0000 (UTC)
    > >User-Agent: G2/0.2
    > >Complaints-To:
    > >Injection-Info: z14g2000cwz.googlegroups.com;

    posting-host=68.235.175.182;
    > > posting-account=RQCAeA0AAAD3LqKwWkK7dT5s5xKt50OA
    > >Path:

    >

    cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!tornado.fastwebnet.it!tiscali!new
    >

    sfeed1.ip.tiscali.net!news.glorb.com!postnews.google.com!z14g2000cwz.googleg
    > roups.com!not-for-mail
    > >Xref: cpmsftngxa10.phx.gbl

    > microsoft.public.dotnet.framework.aspnet.webservices:27371
    > >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
    > >
    > >All,
    > >
    > >I have a windows service that passes a dataset to a webmethod. The
    > >webmethod then puts the dataset into a private message queue. I
    > >created the proxy for the webmethod in visual studio, by adding a
    > >reference to the webmethod, not using wsdl.exe manually.
    > >
    > >Initially I flushed out the code calling the synchronous version of

    the
    > >generated proxy for the webmethod. This worked fine and I was able

    to
    > >see the datasets transferred properly to the private queue via the
    > >webmethod.
    > >
    > >Subsequently I changed the implementation to use the asynchronous
    > >version of the webmethod's proxy. Everything seemed to be working
    > >fine, datasets were arriving in the private queue and callbacks

    firing
    > >fine.
    > >
    > >Today I implemented the queue drainer and found that there were no

    rows
    > >in the datasets that I was pulling out of the private queue. After
    > >awhile I traced it back to the fact that there were no rows in the
    > >dataset received by the webmethod. It turns out that if I revert to
    > >calling the synchronous version of the proxy, the dataset is

    properly
    > >transferred (with rows) to the webmethod and subsequently to the
    > >private queue.
    > >
    > >I have attempted to regenerate the proxy and there is no change in
    > >behavior.
    > >
    > >This seems quite odd. Does anyone have reference indicating that a
    > >difference exists between the serialization performed on datasets in
    > >synchronous calls vs. asynchronous calls?
    > >
    > >Thanks in advance,
    > >
    > >Dustin
    > >Newbrook Solutions
    > >www.newbrooksolutions.com
    > >
    > >


    I found that the error was occuring due to a race condition. The
    BeginInvoke() method of the proxy does not generate a deep copy of the
    DataSet. I was making a call to the DataSet.Clear() method after
    calling my web proxy. In the synchronous call this works fine as the
    dataset has already been serialized and sent. In the asynchronous call
    it causes the DataSet to be cleared before the DataSet is actually
    serialized down (at least this is my best guess). I removed the call to
    DataSet.Clear() and it is working fine.

    Dustin
     
    Dustin, Jan 4, 2005
    #3
    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. Randy Hayes
    Replies:
    0
    Views:
    124
    Randy Hayes
    Dec 21, 2003
  2. Randy Hayes
    Replies:
    1
    Views:
    151
  3. Randy Hayes
    Replies:
    1
    Views:
    219
  4. Steven
    Replies:
    0
    Views:
    372
    Steven
    Nov 30, 2005
  5. John Ramsden

    Async Message Passing Mechanism Wanted

    John Ramsden, Jun 25, 2003, in forum: Perl Misc
    Replies:
    0
    Views:
    115
    John Ramsden
    Jun 25, 2003
Loading...

Share This Page