07.11.2014 Views

Enterprise Library Test Guide - Willy .Net

Enterprise Library Test Guide - Willy .Net

Enterprise Library Test Guide - Willy .Net

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

244<br />

<strong>Enterprise</strong> <strong>Library</strong> <strong>Test</strong> <strong>Guide</strong><br />

Solution<br />

The FormattedDatabaseTraceListener class is already thread safe, so there is no need<br />

to lock the database trace listener. The solution is to set the IsThreadSafe property to<br />

true in the FormattedTraceListenerBase class. This is the base class of the Formatted-<br />

DatabaseTraceListener class. The following is the modified code.<br />

public abstract class FormattedTraceListenerBase : TraceListener, IInstrumentationEventProvider<br />

{<br />

public override bool IsThreadSafe<br />

{<br />

get<br />

{<br />

return true;<br />

}<br />

}<br />

}<br />

Verification<br />

Running the test case again after applying the preceding code verified that the database<br />

trace listener was scalable.<br />

<strong>Test</strong>ing the Cryptography Application Block<br />

The Cryptography Application Block was tested to determine the cost of reading a<br />

symmetric key from a key file. To pass the test, the cost could be slightly more than<br />

when using <strong>Enterprise</strong> <strong>Library</strong> version 1.1 or when using one of the symmetric algorithm<br />

classes in the .NET Framework 2.0 System.Security.Cryptography namespace.<br />

<strong>Test</strong> Case<br />

To run the test case, a key file was first generated with the <strong>Enterprise</strong> <strong>Library</strong> Configuration<br />

Console. The data protection scope could be either current user or local<br />

machine. The test case called the application block’s KeyManager.Read method to<br />

read the symmetric key.<br />

Problems<br />

The test case revealed two problems. The first problem was that reading the key from<br />

the file for each request was an expensive I/O operation that caused poor performance.<br />

The second problem was that to read keys from an input stream, the application<br />

block used the .NET Framework FileStream class. It constructed FileStream<br />

objects with read/write access to the file. When concurrent users tried to access the<br />

file, the .NET framework threw a System.IO.IOException exception. The following<br />

error message displayed:<br />

The process cannot access the file because it is being used by another process.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!