[ASP .NET] CacheItemRemovedCallback

[dixon]

Beste medetweakers,

ik heb een website draaien die op twee verschillende tijdstippen per dag een grote taak heeft uit te voeren. Om dit te realiseren heb ik het volgende artikel gebruikt:

http://www.codeproject.com/KB/aspnet/ASPNETService.aspx

Het probleem: de procedure die is gekoppeld aan de callback wordt twee keer (vrijwel gelijk of iig direct achter elkaar) aangeroepen. Dit is zeer ongewenst. Ik heb al van alles geprobeerd met bijvoorbeeld Application.Lock en Application variables om te kijken of de procedure niet al draait maar dit mocht niet baten.

Is het normaal dat IIS een callback van een item in cache tweemaal aanroept (of eigenlijk tweemaal removed en beide met reason = expired)? Is dit gedrag te veranderen? Zo niet, hoe voorkom ik dat de procedure tweemaal wordt uitgevoerd?

(ik ben vast bezig met de code in global.asax.vb uit te kleden voor het geval iemand deze wil inzien)

[dixon]

Niemand hier ervaring mee? Ik heb al gezocht op het forum en vond wel berichten m.b.t IIS en Caching maar niets over een dubbele aanroep van verwijderde items....

[Daspeed]

Hier rekening mee gehouden?

When using a CacheItemRemovedCallback make sure that you make the callback method ("RemovedCallback" in the sample above) a static method.
If you use an instance method the whole page where the method is defined (including any controls on it or any other data associated with the page) will be stick around in memory for the period that the object is stored in cache. This is because the CacheItemRemovedCallback will need to call into the method of the page object once the cached object is removed from cache. With a static method however the page does not need to stay around so it can be garbage collected appropriately. See http://blogs.msdn.com/tess/archive/2006/08/11/695268.aspx for more info on this

Also take care if you refresh the item in the CacheItemRemovedCallback as this can lead to stackoverflow exceptions if done inappropriately. See http://blogs.msdn.com/tes...ovedcallback-part-ii.aspx for more information on this.

(staat onderaan http://msdn.microsoft.com...eitemremovedcallback.aspx)

Laat verder eens wat code zien?

edit: hier lijkt overigens iemand te zijn met hetzelfde probleem --> http://www.dotnetmonster....cheDependency-Fires-twice
(zijn callback method is overigens geen Static/Shared)

[ Voor 8% gewijzigd door Daspeed op 10-11-2008 13:39 ]

[dixon]

Daspeed: super bedankt voor je antwoord, ik ga het zo bekijken en dan kom ik met feedback. Vreemd dat ik dit zelf niet heb gevonden.

[Niemand_Anders]

En waarom zou je niet gewoon een exe maken en deze vanuit de windows schedular draaien? Je kunt vanaf die plaats bijvoorbeeld een url aanroepen die een taak voor je uitvoert of je voert die taak al vanuit de exe uit.

Een cache callback is nou niet echt een betrouwbaar schedular principe. Wil je het betrouwbaarder krijgen dan zou je kunnen kijken naar een Mutex. Die zijn systeemwijd en je kunt geen tweede Mutex met dezelfde naam (check de derde parameter 'createdNew') of de Mutex is toegewezen. Op het moment dat createdNew false is kun je dan direct de callback verlaten. Application.Lock voorkomt niet dat de procedure voor de tweede maal wordt aangeroepen, maar dat ze 'sequentieel' worden uitgevoerd..

Als je een Mutex gaat werken moet je niet vergeten de Mutex weer vrij te geven (ReleaseMutex).

[dixon]

Niemand_Anders: middels een executable een url aanroepen die de taak uitvoert is nog wel een idee wat het zou kunnen oplossen. Maar, het systeem heeft goed gewerkt. Dat een cache callback niet betrouwbaar is heb ik niet veel van gemerkt. Behalve dan dat het tweemaal is uitgevoerd in plaats van eenmaal.

Een Mutex heb ik wel eerder gebruikt onder Windows applicaties. Zal ik ook naar kijken, bedankt!

[dixon]

Het is opgelost. Beide bedankt voor jullie antwoorden. Daspeed had het juiste antwoord; de callback procedure moest inderdaad een static method zijn (in VB een 'Shared Method'), zo dus:

code:

        Private Shared Sub CacheItemRemovedCallback(ByVal key As String, ByVal value As Object, ByVal reason As CacheItemRemovedReason)

Een paar opmerkingen; alle subs en functies je vanuit CacheItemRemovedCallback gebruikt moeten ook Shared worden. Bovendien is het vanuit een Shared method niet meer mogelijk om gebruik te maken van Application("variable"). Ik maak hier wel gebruik van en heb dit dan ook als volgt opgelost:

code:

        Private Shared m_objApp As HttpApplicationState
        Public Shared Property App() As HttpApplicationState
            Get
                Return m_objApp
            End Get
            Set(ByVal value As HttpApplicationState)
                m_objApp = value
            End Set
        End Property

        Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
            ' code verwijderd..

            App = Application
        End Sub

Ik bewaar de HttpApplicationState dus in een Shared Member Variable. Vervolgens kan je vanuit andere pages hiernaar verwijzen met [Global].App("variable"). Volgens mij zou ik vanaf de andere pages ook moeten kunnen naar verwijzen naar Application("variable") maar dit heb ik niet getest. Dit werkt in ieder geval goed!

[Daspeed]

Mooi dat't nu werkt. Ik ben't overigens wel met Niemand_Anders eens dat't wellicht netter is om gewoon een executable te schedulen.

[dixon]

Tja, helaas heb ik geen toegang tot de 'Scheduled Tasks'. Zelfde geldt voor Windows services.

Vooralsnog is middels Cache een goede methode. Mocht dit stoppen met werken dan vraag ik de benodigde rechten aan om het met een van bovenstaande methodes op te lossen.