Web Service C#, considerazioni su la sincronizzazione di un metodo

venerdì 04 gennaio 2008 - 13.58

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

v.iacono Profilo | Newbie

7 messaggi | Data Invio: ven 4 gen 2008 - 13:58

Ciaooo,
Sono uno svilupparore in una societ¨¤ IT.
Sto sviluppando un WS e ,i trovo davanti a un dilemma, potete aiutarmi.

Riassunto della quesione:
Mi è chiara la differenza tra Mutex e Monitor.
Ma consideriamo il seguente scenario, si vuole progettare un web service per integrare due diversi ambienti.
Non appena parte il web service, viene messo in cache un oggetto che avrà uno scopo di tipo application e un oggetto di scopo application per effettuare la sincronizzazione.
Si presume che piu' client possano interagire con il Web Service contemporaneamente. Il metodo invocato dovrà utilizzare l'oggetto e necessariamente si dovrà sincronizzarne l'accesso, in quanto sicuramente ci saranno più richieste in parallelo.
A questo punto cosa bisogna usare un Monitor o un Mutex? Quando arriva la richiesta di un client IIS crea un thread che è nello stesso proces boundaries o AppDomain?? Se no, sarebbe necessario utilzzare un Mutex, vi pare?

Il Web service ha solo un web metodo che chiamiamo wsm. Quando viene chiamato wsm, si dovr¨¤ accedere IN MODO SINCRONO ad un oggetto che ho precedentemente caricato in cache.

In questo modo
void Application_Start(object sender, EventArgs e)
{
ApplicationCache.loadApplicationCache();
}

La classe rappresentante l'oggetto ¨¨ la seguente
public class ApplicationCache
{
public ApplicationCache()
{
//
// TODO: Add constructor logic here
//
}

static private cRegolaClass _rcCache = null;
static public Object thislock;
static private cRegolaClass _rcCommerciale = null;
static public Object secondLock;

static public cRegolaClass rcCache
{
get { return _rcCache; }
//set{_rcCache = value;}
}

static public cRegolaClass rcCacheCommerciale
{
get { return _rcCommerciale; }
//set{_rcCache = value;}
}

public static void loadApplicationCache()
{
OxRegolaDotNet.cRegolaClass rc = new OxRegolaDotNet.cRegolaClass();
rc.Load(@"C:\srcNGRF\Progetti\RicercaFornitori\AZIONI.xml");
rc.EvalType = eEvalType.EvalByFactor;
_rcCache = rc;
OxRegolaDotNet.cRegolaClass rcCommerciale = new OxRegolaDotNet.cRegolaClass();
rcCommerciale.Load(@"C:\srcNGRF\Progetti\RicercaFornitori\COMMERCIALE.xml");
rcCommerciale.EvalType = eEvalType.EvalByFactor;
_rcCommerciale = rcCommerciale;
thislock = new Object();
secondLock = new Object();
}

}

Come si vede abbiamo un metodo statico che carica in memoria due oggetti, per semplicit¨¤ diciamo uno.
Inoltre questo oggetto contiene internamente un oggetto per sincronizzare l'accesso alla risorsa stessa.

All'iterno del metodo web per sincronizzare l'accesso all'oggetto vengono utilizzati i Monitor invece dei Mutex.

Vediamo come ¨¨ realizzato all'interno del metodo, la parte utilizzata per sincronizzare la risorsa

try
{ /*(1)
* Elimina spazio dei nodi dall'xml ricevuto in input
*/
string sXml2 = wsInputXml.InnerXml.Replace("xmlns=\"http://tempuri.org/\"", "");
wsInputXml.LoadXml(sXml2);

/*(1.1)
*Formatta prodotto
*/
if (wsInputXml.SelectSingleNode("//codiceProdotto").InnerText != "")
{
int temp;
temp = Int32.Parse(wsInputXml.SelectSingleNode("//codiceProdotto").InnerText.Substring(12, );
wsInputXml.SelectSingleNode("//codiceProdotto").InnerText = temp.ToString();
}

/* (2) Valuta la regola secondo i parametri di input
* THREADSAFE SECTION 1
*/
Monitor.Enter(ApplicationCache.thislock);
try
{
ApplicationCache.rcCacheCommerciale.SetAllFactorToEmpty();
cRegolaClass regTem = ApplicationCache.rcCacheCommerciale;
/* (2.1)
* Setta i fattori della regola
*/
settaFattoriCommerciale(ref regTem, wsInputXml);
/*
* Valuta regola
*/
regTem.EvalRule();
sXmlLocal = regTem.Result.GetXML("parametersReturn", "row");

}
finally
{
Monitor.Exit(ApplicationCache.thislock);
}

oXmlRetParamsLocal.LoadXml(sXmlLocal);

/* (3)
* THREADSAFE SECTION 2
*/
Monitor.Enter(ApplicationCache.secondLock);
try
{
ApplicationCache.rcCache.SetAllFactorToEmpty();
cRegolaClass regTem2 = ApplicationCache.rcCache;
valutaRegole(oXmlRetParamsLocal, ref regTem2, "parametersReturn");
regTem2.EvalRule();
oXmlRetParamsLocal.LoadXml(regTem2.Result.GetXML("parametersReturn", "row"));
}
finally
{
Monitor.Exit(ApplicationCache.secondLock);
}

Il DILEMMA:
Sapendo che - At the operating-system level, there

are three kernel objects¡ªMutex, Semaphore, and Event

For example, using a Mutex to synchronize your threads instead of a Monitor is about 33 times slower (as pointed out by Jeffrey Richter in his book CLR via C#, mentioned earlier in this chapter). Even

though these kernel objects come with additional overhead, they allow you to perform synchronization tasks that are impossible with the Monitor and ReaderWriterLock classes:

¡ö A Mutex allows synchronization (like a lock) across AppDomain and process

boundaries.

Posso essere sicuro che i Monitor in questo caso si possano utilizzare????
IIS quando soddisfa le richieste crea piu'thread in uno stesso processo o appDomain???
Io Aspetto richieste di chiarimenti allora mi raccomando...
non vedo l'ora di dibattere su questo argomento

v.iacono Profilo | Newbie

7 messaggi | Data Invio: lun 7 gen 2008 - 11:02

Possibile che nessuno ne sappia niente???

Finalmente ho trovato qualcuno che mi ha risposto
Dipende da come hai configurato IIS e dal tipo di concorrenza che hai. Nella configurazione normale (appPool in un solo processo), hai un solo processo con un solo appDomain per il tuo applicativo e quindi basta Monitor. Altrimenti se hai più appDomain (più processi per il medesimo appPool) devi decidere se la concorrenza è su qualcosa tipo file o db e l'accesso deve gestito, oppure devi accedere ad una collezione o variabile a livello di applicazione?
Nel primo caso devi andare di Mutex nel secondo di Monitor

Allora che ne pensate?

Dott.

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !