XmlDataSource caches between page loads?

  • Thread starter Thread starter Wessel Troost
  • Start date Start date
W

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
 
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


WT> We are using an XML data source in the Page_Load event of an ASP.NET
WT> page, like:
WT>
WT> protected void Page_Load(object sender, EventArgs e)
WT> {
WT> // Retrieve XML from web service for product idea in URL
WT> string sXML = GetXmlFromWebService(Request["ProductID"]);
WT> XmlDataSource ds = new XmlDataSource();
WT> ds.Data = sXML;
WT> // Display data on web page
WT> }
WT> Now the weirdest thing is that the XML is actually *cached* between
WT> page loads. The first product is shown correctly, but the next page
WT> request always shows the first product. I've used the debugger to
WT> verify that GetXmlFromWebService returns the correct XML for the new
WT> product. But the XmlDataSource seems to ignore the new XML, even
WT> though it's newly created.
WT>
WT> Anyone have a clue what's going on?
WT>
WT> TIA,
WT> Wesse
 
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
 
Hello Wessel,

http://msdn2.microsoft.com/en-us/library/system.web.ui.webcontrols.xmldatasource.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


WT> Hi Michael,
WT>
WT> Thanks for your reply. We did indeed figure out how to fix the
WT> behaviour, but we were wondering what causes it.
WT>
WT> We are creating a new XmlDataSource with a new XML string. How does
WT> the system decide to cache this? Does it assume every XmlDataSource
WT> on every page only gets the exact same XML? Is the cache AppDomain
WT> wide, or just for the particular ASP.NET thread?
WT>
WT> Any tips or hyperlinks which might shed light on this matter
WT> appreciated :)
WT>
WT> -Wessel
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

WT> We are using an XML data source in the Page_Load event of an
ASP.NET
WT> page, like:
WT>
WT> protected void Page_Load(object sender, EventArgs e)
WT> {
WT> // Retrieve XML from web service for product idea in URL
WT> string sXML = GetXmlFromWebService(Request["ProductID"]);
WT> XmlDataSource ds = new XmlDataSource();
WT> ds.Data = sXML;
WT> // Display data on web page
WT> }
WT> Now the weirdest thing is that the XML is actually *cached*
between
WT> page loads. The first product is shown correctly, but the next
page
WT> request always shows the first product. I've used the debugger to
WT> verify that GetXmlFromWebService returns the correct XML for the
new
WT> product. But the XmlDataSource seems to ignore the new XML, even
WT> though it's newly created.
WT>
WT> Anyone have a clue what's going on?
WT>
WT> TIA,
WT> Wessel
 
http://msdn2.microsoft.com/en-us/library/system.web.ui.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?
 
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
 
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


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
 
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
 
Back
Top