Vi lascio un post che spiega in dettaglio i motivi per cui un’applicazione che “gira” in debug(F5 con Visual Studio) è sensibilmente più lenta di una senza il debugger agganciato.

Ecco il link, buona lettura

Recentemente mi è capitato di dover effettuare delle validazioni di login di utenti all’interno di un dominio, per fare questo ho utilizzato le classi  “Directory Services” di .NET 3.5(System.DirectoryServices.AccountManagement.dll).

Lo snippet di codice C# è davvero semplice:

using System.DirectoryServices.AccountManagement;

…

bool valid = new PrincipalContext(ContextType.Domain, "machine name/ip")
                  .ValidateCredentials(“userName”,”password”,ContextOptions.Negotiate);

…

logicamente il nome macchina, userName e password devono essere reali(spero che nessuno usi questa naming convention :-) ).

Lascio come riferimento l’articolo di MSDN Magazine che illustra tutte le potenzialità di questa API(fanno molto di più che validare la user name e la password di un utente).

Fonti: http://msdn.microsoft.com/en-us/magazine/cc135979.aspx

La necessità di dover introdurre il concetto di “programmazione parallela” in modo più semplice possibile nelle menti di noi sviluppatori a causa dell’annuciato tramonto della famosa prima legge di Moore, ha portato il team del CLR a dover effettuare delle sostaziali modifiche nel funzionamento del ThreadPool che ci troveremo nel framework 4.0.

Le principali modifiche apportate sono le seguenti:

-Il ThreadPool funziona come una coda di workItem che vengono schedulati on demand, fino ad oggi la coda è stata implementata come una semplice linked list protetta da un Monitor. Questa tecnica diventa poco efficiente in caso di molti workload brevi, dovuti alla sincronizzazione della coda, inoltre il garbage collector è molto dispendioso nello scorrere questo tipo di struttura e liberarla in caso di necessità. Nel nuovo ThreadPool la coda è implementata con dei “chunk”(array) di workItem collegati. Questa tecnica permette di abbassare il lock necessari all’inserimento dei workItem(è necessario solo un’operazione atomica per incrementare l’indice nell’array) e permette al garbage collector di essere più efficente nella fase di collect.

-La modalità di scheduling utilizzerà l’algoritmo di “working stealing queue”, un meccanismo che permette di abbassare drasticamente il bisogno di lock e di mantere al massimo il consumo di CPU migliorando le prestazione complessive

-miglioria della funzionalità di “thread injection” che permette di regolare il numero di thread in gioco in modo dinamico così da utilizzare tutta la CPU disponibile

Alcune di queste features sono nate dalla stretta collaborazione con il PFX team(Parallel Framework Team) che fa largo uso di queste tecniche per ottimizzare il parallelismo all’interno delle Task Parallel Library.

Tutti questi nuovi meccanismi potete provarli nella Beta 1 di Visual Studio 2010 con il Framework 4.0 scaribili qui.

Vi lascio alcuni interessanti post e video sull’argomento

Daniel Moth post
Eric Eilebrecht post
Channel 9 video con Eric Eilebrech
Joe Duffy post

Ve la riporto paro paro:

“The Decision

After carefully considering all the options and talking to our customers, partners, and MVPs it was decided to deprecate OracleClient as a part of our ADO.NET roadmap

…

We strongly recommend customers to use  our partners’ ADO.NET Provider for Oracle  instead of continuing to use Microsoft’s OracleClient for new application development”

…però…

Fonte:http://blogs.msdn.com/adonet/archive/2009/06/15/system-data-oracleclient-update.aspx

Parlando con il mio collega Fabioriguardo un progetto che sta seguendo, abbiamo convenuto che sarebbe utile avere la possibilità di sapere se un file è in utilizzo da qualche processo, per permetterci di attendere che venga liberato per essere elaborato dalla nostra procedura.

Girando un pò in internet ho visto che la soluzione più gettonata è quella di mettere un bel(battuta) try{…}cath(IOException){…} e nel catch valutare il dafarsi.

Questa soluzione non mi piace principalmente per 3 motivi:

1)Usare le eccezioni per una cosa che potrebbe non essere una “eccezione” non mi sembra corretto, io sono della fazione che tratta le eccezioni come un evento inaspettato e non un modo per fare logiche di business.

2)Sollevare e gestire una eccezione è dispendioso e se c’è la possibilità preferisco evitare di pagare questo prezzo.

3)Spesso il tipo di eccezione non individua precisamente il problema dove sta, a meno che non facciamo del “parsing” su qualche proprietà di essa, in quanto un tipo di eccezione può raggruppare più tipo di errori.

Detto questo(attenzione ho detto non MI piace, tutto è opinabile, avete il mio contatto se volete che ne parliamo approfonditamente), ho deciso di cercare un modo più “pulito” per risolvere questo problema e sono arrivato alla soluzione che consiste nello scrivere un extension method alla classe System.IO.FileInfo che controlla attraverso l’utilizzo di una API(nello specifico CreateFile)del sistema operativo se il file in questione è utilizzato da qualche altro processo.

Il pattern di utilizzo è abbastanza semplice:

//Creo il FileInfo
var fileInfo = new FileInfo(path);
//Controllo se il file è usato
Console.WriteLine("File usato: {0}", fileInfo.IsUsingByAnotherProcess());

per poterlo utilizzare dobbiamo avere visibilità sulla classe FileInfoExtension che contiene l’extension method.

Questo metodo tuttavia non è perfetto, o meglio, soffre di “race condition” ovvero se tra la chiamata IsUsingByAnotherProcess() e l’apertura del file(per processarlo) qualcuno si mette in mezzo possiamo comunque prenderci una bella eccezione per file usato da un’altro processo, ma in quel caso possiamo correttamente gestire l’eccezione come meglio ci pare(quì si che non ci aspettavamo di trovarlo occupato di nuovo). Il caso più utile in cui questo metodo può essere usato è quando sappiamo che qualcuno potrebbe “usare” il file e poi tocca a noi…per esempio un upload di file e scheduled task che elabora il file, quì è chiaro che solo noi e l’upload possono usare il file e in ordine prevedibile. Nel caso questo non fosse il vostro caso potete gestirlo nel catch(IOException) ancora attraverso questo extension method così da essere certi che il problema sia ancora quello, riprovando succesivamente l’operazione.

Potete scaricare il codice di esempio FileInfoExtension.zip (40,61 kb)

Se qualcuno ha qualche idea migliore o qualcosa da aggiungere, prego!

------------------------

Ho mandato un feedback a microsoft sulla problematica, ma dicono che non hanno pianificato di aggiungerlo nella versione 4.0 e che qualcun altro aveva già sottolineato una mancanza in questa api, lascio il link del feedback http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=468166 , magari in una versione futura fanno qualcosa.

Capita non di rado in alcune applicazioni di avere la possibilità di interrompere qualche operazione “lunga” o “asincrona” a fronte della richiesta di qualche operatore sia esso un’utente comune o un agente software. Questa operazione spesso sottovalutata dovrebbe essere conclusa senza portare il sistema in uno stato inconsistente in tutti i sensi, per tutti i sensi intendo sia dal punto di vista “tecnico”(es:stabilità del processo, risorse etc..), sia dal punto di vista dello stato dei dati in questione(es:una griglia su un form).

Questo significa che qualunque sia il tipo di operazione da interrompere, questa deve essere conscia del fatto che qualcuno ha deciso che deve smettere di fare quello che sta facendo senza provocare danni.

Con questo problema si sono dovuti scontrare chiaramente il team delle Task Parallel Library(.NET 4.0), riguardo al problema di dover interrompere un’operazione asincrona/parallela.

A fronte di questo hanno deciso di creare un’insieme di classi preposte alla gestione delle “cancellazioni” di operazioni in modo “cooperativo”, tutto questo sotto il nome di  “Cancellation Framework”.

Le classi principali che compongono questo framework sono: CancellationToken che verrà passata all’operazione “interrompibile” per informarla che qualcuno ha richiesto uno stop, e CancellationTokenSource che scatenerà l’interruzione.

La cosa molto interessante è la modalità di comunicazione tra CancellationTokenSource e CancellationTokens (potrebbero essere più di uno, potremmo richiedere lo stop a più operazioni asincrone/parallele contemporaneamente). Possiamo effettuare un polling sulla proprietà IsCancellationRequested dell’oggeto CancellationToken o registrare una callback che verrà eseguita alla richiesta della cancellazione.

Questi tipi di pattern sono già stati implementati in molte classi del framework, ma ogni implementazione ha sempre avuto un suo set di classi personalizzate. L’idea di avere un framework comune mi sembra ottima, sarebbe molto più facile scrivere codice più “generico” e adattabile a contesti diversi, oltre che corretto nella sua implementazione (ci sono molte cose non banali da gestire, la sincronizzazione etc…).

Per una più dettagliata spiegazione dell’argomento vi lascio il post del pfxTeam.

Il concetto che per avere migliori performance dobbiamo usare meno thread fisici possibili e di conseguenza meno risorse( magari 1 thread per core ), viene usato anche all’interno delle nuove Task Parallel Library ( .NET Framework 4.0 ) riguardo agli oggetti Task.

Cio significa che se abbiamo un ciclo for parallelo ( Parallel.For/ForEach ), non è detto che per ogni iterazione avremo un’oggetto Task che verrà schedulato, ma l’odierna implementazione prevede che ogni Task processi un chunk di operazioni ( iterazioni diciamo ), così da abbassare l’overhead della creazione e gestione degli stessi.

Ciò potrebbe portare a subdoli problemi, come nel caso in cui ci siano delle dipendenze tra le iterazioni che potrebbero mandare in deadlock il loop.

Se vi interessa un’approfondimento sulla tematica vi consiglio di dare una letta a questo post del pfxTeam :

http://blogs.msdn.com/pfxteam/archive/2009/05/26/9641563.aspx

Per un progetto su cui sto lavorando ho bisogno di avere tutti i giorni di un dato mese passando come parametri l’anno e il mese.

Dopo aver preso spunto dall’idea di Itzik Ben-Gan dal suo libro “Inside SQL Server 2005 T-SQL Programming” sono arrivato a questa soluzione( è la bozza diciamo ).

set dateformat ymd
declare @year int,@month int
set @year = 2009
set @month = 6
;with
    L0 as (select 1 as c union all select 1 ),
    L1 as (select 1 as c from L0 as A,L0 as B),
    L2 as (select 1 as c from L1 as A,L1 as B),
    L3 as (select 1 as c from L2 as A,L2 as B),
    L4 as (select 1 as c from L3 as A,L3 as B),
    L5 as (select 1 as c from L4 as A,L4 B),
    Nums as (select row_number() over(order by c) as n from L5)
select CAST(    CAST(@year as nvarchar(4))  + N'-' +
                CAST(@month as nvarchar(2)) +N'-' +
                CAST( n  as nvarchar(2)) as datetime) as dt 
from Nums where n <= 31 and
                ISDATE(CAST(@year as nvarchar(4))  + N'-' +
                CAST(@month as nvarchar(2)) +N'-' +
                CAST( n  as nvarchar(2))) = 1

Questa query ritorna il set di date del mese di giugno dell’anno 2009.
Lo script fa uso delle CTE, funzioni di Ranking e funzioni sulle date. Funziona con le versioni di SQL Server che supportano queste features, io la sto usando su SQL Server 2005.