XmlDataSource caches between page loads?

[Wessel Troost]

We are using an XML data source in the Page_Load event of an ASP.NET
page, like:

protected void Page_Load(object sender, EventArgs e)
{
// Retrieve XML from web service for product idea in URL
string sXML = GetXmlFromWebService(Request["ProductID"]);

XmlDataSource ds = new XmlDataSource();
ds.Data = sXML;

// Display data on web page
}

Now the weirdest thing is that the XML is actually *cached* between
page loads. The first product is shown correctly, but the next page
request always shows the first product. I've used the debugger to
verify that GetXmlFromWebService returns the correct XML for the new
product. But the XmlDataSource seems to ignore the new XML, even
though it's newly created.

Anyone have a clue what's going on?

TIA,
Wessel

[Michael Nemtsev [MVP]]

Hello Wessel,

Caching is enabled for XmlDataSource by default. U need to use XmlDataSource::EnableCaching
property to set false

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
WTWe are using an XML data source in the Page_Load event of an ASP.NET
WTpage, like:
WT>
WTprotected void Page_Load(object sender, EventArgs e)
WT{
WT// Retrieve XML from web service for product idea in URL
WTstring sXML = GetXmlFromWebService(Request["ProductID"]);
WTXmlDataSource ds = new XmlDataSource();
WTds.Data = sXML;
WT// Display data on web page
WT}
WTNow the weirdest thing is that the XML is actually *cached* between
WTpage loads. The first product is shown correctly, but the next page
WTrequest always shows the first product. I've used the debugger to
WTverify that GetXmlFromWebService returns the correct XML for the new
WTproduct. But the XmlDataSource seems to ignore the new XML, even
WTthough it's newly created.
WT>
WTAnyone have a clue what's going on?
WT>
WTTIA,
WTWessel

[Wessel Troost]

Hi Michael,

Thanks for your reply. We did indeed figure out how to fix the
behaviour, but we were wondering what causes it.

We are creating a new XmlDataSource with a new XML string. How does
the system decide to cache this? Does it assume every XmlDataSource on
every page only gets the exact same XML? Is the cache AppDomain wide,
or just for the particular ASP.NET thread?

Any tips or hyperlinks which might shed light on this matter
appreciated :)

-Wessel

On 27 apr, 16:44, Michael Nemtsev [MVP] <[e-mail]:

Hello Wessel,

Caching is enabled for XmlDataSource by default. U need to use XmlDataSource::EnableCaching
property to set false

---
WBR,
Michael *Nemtsev [.NET/C# MVP] :: blog:http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

WTWe are using an XML data source in the Page_Load event of an ASP.NET
WTpage, like:
WT>
WTprotected void Page_Load(object sender, EventArgs e)
WT{
WT// Retrieve XML from web service for product idea in URL
WTstring sXML = GetXmlFromWebService(Request["ProductID"]);
WTXmlDataSource ds = new XmlDataSource();
WTds.Data = sXML;
WT// Display data on web page
WT}
WTNow the weirdest thing is that the XML is actually *cached* between
WTpage loads. The first product is shown correctly, but the next page
WTrequest always shows the first product. I've used the debugger to
WTverify that GetXmlFromWebService returns the correct XML for the new
WTproduct. But the XmlDataSource seems to ignore the new XML, even
WTthough it's newly created.
WT>
WTAnyone have a clue what's going on?
WT>
WTTIA,
WTWessel

[Michael Nemtsev [MVP]]

Hello Wessel,

http://msdn2.microsoft.com/en-us/lib...atasource.aspx

"The XmlDataSource automatically caches data when the EnableCaching property
is set to true, and the CacheDuration property is set to the number of seconds
that the cache stores data before the cache is invalidated. You can use the
CacheExpirationPolicy to further fine-tune the caching behavior of the data
source control.
"

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
WTHi Michael,
WT>
WTThanks for your reply. We did indeed figure out how to fix the
WTbehaviour, but we were wondering what causes it.
WT>
WTWe are creating a new XmlDataSource with a new XML string. How does
WTthe system decide to cache this? Does it assume every XmlDataSource
WTon every page only gets the exact same XML? Is the cache AppDomain
WTwide, or just for the particular ASP.NET thread?
WT>
WTAny tips or hyperlinks which might shed light on this matter
WTappreciated :)
WT>
WT-Wessel
WT>
WTOn 27 apr, 16:44, Michael Nemtsev [MVP] <[e-mail]:
WT>

>Hello Wessel,

Caching is enabled for XmlDataSource by default. U need to use
XmlDataSource::EnableCaching property to set false

---
WBR,
Michael Nemtsev [.NET/C# MVP] :: blog:http://spaces.live.com/laflour
"The greatest danger for most of us is not that our aim is too high
and we miss it, but that it is too low and we reach it" (c)
Michelangelo

WTWe are using an XML data source in the Page_Load event of an
ASP.NET
WTpage, like:
WT>
WTprotected void Page_Load(object sender, EventArgs e)
WT{
WT// Retrieve XML from web service for product idea in URL
WTstring sXML = GetXmlFromWebService(Request["ProductID"]);
WTXmlDataSource ds = new XmlDataSource();
WTds.Data = sXML;
WT// Display data on web page
WT}
WTNow the weirdest thing is that the XML is actually *cached*
between
WTpage loads. The first product is shown correctly, but the next
page
WTrequest always shows the first product. I've used the debugger to
WTverify that GetXmlFromWebService returns the correct XML for the
new
WTproduct. But the XmlDataSource seems to ignore the new XML, even
WTthough it's newly created.
WT>
WTAnyone have a clue what's going on?
WT>
WTTIA,
WTWessel

[Wessel Troost]

http://msdn2.microsoft.com/en-us/lib...webcontrols.xm...

>

That's from the online documentation-- we've read that :)

Cashing an XML file makes sense, you could keep a list of filename +
parsed XML.

But how does it cache a random incoming string? What is the "key" of
the cache, to determine if a new "ds.Data = sXML;" statement hits the
cache?

If we'd load a from a different function, would it hit the cache? A
different page? A different AppDomain?

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

If it is that problematic, you could try just loading the XML into a DataSet
via ReadXml, and handle whatever caching you may need by yourself.
-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site: http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://ittyurl.net
"Wessel Troost" wrote:

http://msdn2.microsoft.com/en-us/lib...webcontrols.xm...

That's from the online documentation-- we've read that :)

Cashing an XML file makes sense, you could keep a list of filename +
parsed XML.

But how does it cache a random incoming string? What is the "key" of
the cache, to determine if a new "ds.Data = sXML;" statement hits the
cache?

If we'd load a from a different function, would it hit the cache? A
different page? A different AppDomain?

[Wessel Troost]

Hi Peter,

Thanks for your reply. It's not problematic-- we've solved it-- it's
just that we are wondering how this caching works. So we can avoid
problems with it in the future.

Greetings,
Wessel

On 28 apr, 03:09, Peter Bromberg [C# MVP]
<[e-mail]:

If it is that problematic, you could try just loading the XML into a DataSet
via ReadXml, and handle whatever caching you may need by yourself.
-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site:http://www.eggheadcafe.comhttp://pet...a.blogspot.com
*http://ittyurl.net

"Wessel Troost" wrote:

>http://msdn2.microsoft.com/en-us/lib...webcontrols.xm....

That's from the online documentation-- we've read that :)

Cashing an XML file makes sense, you could keep a list of filename +
parsed XML.

But how does it cache a random incoming string? What is the "key" of
the cache, to determine if a new "ds.Data = sXML;" statement hits the
cache?

If we'd load a from a different function, would it hit the cache? A
different page? A different AppDomain?

[Fernando Rodriguez, MCP]

Wessel:

The XmlDataSource is meant to keep a synchronized version of an XML file in
memory. It will cache the data the CacheDuration time that you set (I
believe the default is indefinite) or when the XML file is modified.\

So I'm pretty sure that the "key" is the fully qualified file name, so since
you're not using a filename it loads the same data for all XmlDataSource
instances without a filename.

It looks like for what you're trying to do, you don't need to be using an
XmlDataSource as it is meant for the scenario described above. I think a
DataSet would be more suitable for your needs.

Hope that helps,
Fernando Rodriguez, MCP
"Wessel Troost" <we**********@gmail.comwrote in message
news:ac**********************************@y21g2000 hsf.googlegroups.com...
Hi Peter,

Thanks for your reply. It's not problematic-- we've solved it-- it's
just that we are wondering how this caching works. So we can avoid
problems with it in the future.

Greetings,
Wessel

On 28 apr, 03:09, Peter Bromberg [C# MVP]
<[e-mail]:

If it is that problematic, you could try just loading the XML into a
DataSet
via ReadXml, and handle whatever caching you may need by yourself.
-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site:http://www.eggheadcafe.comhttp://pet...a.blogspot.com
http://ittyurl.net

"Wessel Troost" wrote:

>http://msdn2.microsoft.com/en-us/lib...webcontrols.xm...

That's from the online documentation-- we've read that :)

Cashing an XML file makes sense, you could keep a list of filename +
parsed XML.

But how does it cache a random incoming string? What is the "key" of
the cache, to determine if a new "ds.Data = sXML;" statement hits the
cache?

If we'd load a from a different function, would it hit the cache? A
different page? A different AppDomain?

[Wessel Troost]

Fernando,

Thanks for your reply, your post clarifies the caching. We tried the
dataset, but it doesn't support XPath data binding. (We're using XPath
queries in the .aspx markup file.)

Greetings,
Wessel

On 30 apr, 23:16, "Fernando Rodriguez, MCP"
<[e-mail]:

Wessel:

The XmlDataSource is meant to keep a synchronized version of an XML file in
memory. It will cache the data the CacheDuration time that you set (I
believe the default is indefinite) or when the XML file is modified.\

So I'm pretty sure that the "key" is the fully qualified file name, so since
you're not using a filename it loads the same data for all XmlDataSource
instances without a filename.

It looks like for what you're trying to do, you don't need to be using an
XmlDataSource as it is meant for the scenario described above. I think a
DataSet would be more suitable for your needs.

Hope that helps,
Fernando Rodriguez, MCP

"Wessel Troost" <[e-mail] in message

news:ac**********************************@y21g2000 hsf.googlegroups.com...
Hi Peter,

Thanks for your reply. It's not problematic-- we've solved it-- it's
just that we are wondering how this caching works. So we can avoid
problems with it in the future.

Greetings,
Wessel

On 28 apr, 03:09, Peter Bromberg [C# MVP]

<[e-mail]:

If it is that problematic, you could try just loading the XML into a
DataSet
via ReadXml, and handle whatever caching you may need by yourself.
-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site:http://www.eggheadcafe.comhttp://pet...a.blogspot.com
http://ittyurl.net

"Wessel Troost" wrote:

http://msdn2.microsoft.com/en-us/lib...webcontrols.xm...

That's from the online documentation-- we've read that :)

Cashing an XML file makes sense, you could keep a list of filename +
parsed XML.

But how does it cache a random incoming string? What is the "key" of
the cache, to determine if a new "ds.Data = sXML;" statement hits the
cache?

If we'd load a from a different function, would it hit the cache? A
different page? A different AppDomain?