SqlSiteMapProvider - extending

[PhatT]

Working off of the Wicked Code article by Jeff Prosise...
http://msdn.microsoft.com/msdnmag/issues/06/02/WickedCode/default.aspx

I am trying to build my sitemap on multiple tables. I have tried this many
different ways with not the ideal results. When building the sitemap with a
storedproc that used a union query everything was working except the cache
would never invalidate. Further research led me to believe that the union's
in my storedproc would cause this. So now I have created separate sp's which
I register for the callback. The same callback function is registered for
each stored proc.

Now I get REAL inconsistent results, but sometimes the results are fine.
IOW - when I first test, it displays only the root node of the treeview
(stepping through it, I see that it builds the whole stinkin sitemap, and
then trashes it, at some point after the second call-back is registered. It
appears that the cache object is removed almost immediately after being
registered.

But then if I click on the root again, it builds all or part of the sitemap
and displays properly.

Sometimes when underlying data is updated, the sitemap refreshes, and
sometimes it doesn't. Sometimes I get partial sitemaps... etc.

Ok, this may not be making any sense, but that is because it isn't making
sense to me either. When I step through the code, it seems to hit the
buildsitemap function a random number of times (but it may be related to the
number of nodes?) and jump out because _root is not null.

Does anyone have a better understanding of how to register multiple
dependencies, or whether I might be doing something wrong - causing immediate
cache object removed for cachedependencychanged events?

Let me know if anyone wants to take a look and I will try to provide some
sensible code... 8o)

 

[PhatT]

Thought I would document some progress. Still Not there... now I wonder if
sql cache dependencies are working.

Here is the latest, I found that redundantly "insert"ing a cache dependency
would result in the object being removed from cache.

Since it appears that the first time a dependency is inserted, it almost
immediately invalidates - but not always - I added logics in my buildsitemap
function to check to see if the cache item already exists...
if (HttpRuntime.Cache.Get("cachekey") == null)
{
....link command to dependency, and insert the dependency into the cache.
}

Now the callback won't fire just because of another dependency being
invalidated - iow the dependency is already registered so don't re-register
it.

This still is inconsistent when you are stepping through the code. because
they all still fire dependency changed once after the first time they are
registered.

Sometimes the results are strange too. I am wondering if it is a threading
issue... but since I have retained all of the _lock segments from Jeff's
code, I am not sure why that would be.

Anyway... Now it at least is a bit more consistent. However, updating the
underlying data is still not firing the event. So to test the theory I added

HttpRuntime.Cache.Remove("CacheKeyNamehere") to my RowUpdating event of one
of my gridviews.... Guess what it worked perfectly.

That obviously defeats the purpose of the sqlcachedependency... But makes me
wonder if SQL Server 2005 Enterprise is incorrectly configured on my laptop...

Any thoughts? (hoping that someone is at least dealing with - or has
already done this successfully)