O femeie recent divortata,isi petrecu prima zi impachetindu-si lucrurile in cutii si valize.A doua zi a venit un camion si a incarcat totul,inclusiv mobila.
A treia zi ,s-a asezat pe jos,in sufrageria goala,a pus muzica in surdina,a asezat doua luminari,doua kile de creveti,o farfurie de icre si o sticla de vin alb pus la gheata.
Cind a terminat de mincat,a demontat toate barele de la perdelele din fiecare camera,le-a scos capacele laterale,a indesat inauntru icrele si crevetii care ii ramasesera,a pus capacele la loc si a asezat din nou barele la geamuri.
Cind s-a intors,fostul sot s-a mutat cu amanta si cu noua lui mobila.In primele zile totul fu perfect.Insa in curind,incet,incet,casa a inceput sa puta.
Au incercat de toate:au facut curatenie,au aerisit…au revizat gurile de ventilatie pentru eventualitatea ca s-ar pute gasi soareci morti inauntru,au spalat covoarele…In fiecare coltisor de casa au pus deodorante electrice,au golit zeci de butelii de spray…Au cheltui o gramada de bani sa schimbe covoarele…In zadar.

Nimic nu functiona.
Nimeni nu le mai venea in vizita,angajatii refuzau sa lucreze si pina si fata care facea curatenie in casa,i-a abandonat.
Disperati,fostul sot si amanta,au hotarit sa se mute.
Dupa o luna inca nu gasisera pe nimeni dispus sa cumpere casa.Cei de la agentiile imobiliare nici nu mai raspundeau la telefon.
In final au cumparat o casa noua.
Intr-o zi,fosta sotie il suna ca sa stabileasca detaliile divortului si din treacat il intreaba cum o mai duce. El raspunde ca vinde casa,fara insa sa-i dea vreo explicatie.

Ea il asculta calma,apoi ii zice ca o sa vorbeasca cu avocatul,sa vada cum ar putea face sa cumpere ea casa.Banuind ca ea n-are nici o idee de adevaratul motiv pentru care o vinde,ii propune a zecea parte din pretul real al locuintei,ca sa scape cit mai repede.Femeia accepta si in citeva ore avocatul ii aduce actele la semnat.
O saptamina mai tirziu,barbatul si amanta se oprira la poarta casei,observind surizatori cum muncitorii impachetau lucrurile si le urcau in camion.

……inclusiv barele de la perdele…


German Dehesa spunea ceva asemanator:
“noi,barbatii ,ar trebui sa intelegem ca femeile sint invincibile,imparabile si de neintrecut”..

Support Certificates In Applications With The .NET Framework 2.0

Certificates are used in many places across the Microsoft® .NET Framework, from secure communication to code signing to security policies. The .NET Framework 2.0 introduced revamped support for certificates and it added a completely new namespace for standards-compliant cryptographic operations with certificates. In this article, I will discuss the background for certificates and the Windows® Certificate Store. I’ll also show you how to work with the certificate APIs and how they are used by the Framework to implement security features.
A “certificate” is really an ASN.1 (Abstract Syntax Notation One) encoded file that contains a public key and additional information about that key and its owner. In addition, a certificate has a validity period and is signed with another key (the so-called issuer) which is used to provide an authenticity guarantee of those attributes and, most importantly, the public key itself. You can think of ASN.1 as a sort of binary XML. Like XML, it also has encoding rules, strong types, and tags; however, these are binary values that often don’t correspond to any printable character.

The name RSA is an acronym for the surnames of three inventors of this algorithm: Ron Rivest, Adi Shamir, and Len Adleman. They formed a company, RSA Security, which published several standard documents called Public Key Cryptography Standards (PKCS). These documents describe several aspects of cryptography.
One of the most popular of these documents, PKCS #7, defines a binary format for signed and encrypted data called the Cryptographic Message Syntax (CMS). CMS is now used in many popular security protocols, including secure sockets layer (SSL) and Secure Multipurpose Internet Mail Extensions (S/MIME). Since it is a standard, it is also the format of choice for when applications need to exchange signed and encrypted data between several parties.


IIS 7.0

The release of IIS 7.0 coincides with the ten-year anniversary of the release of the first version of IIS, in Windows NT® 4.0. In 2001, four versions later, IIS 5.0 became the most prevalent Web server on the Internet, though months later it fell victim to the infamous Code Red and Nimbda worms. IIS 6.0, released in Windows Server® 2003, was a major rewrite of the server, focused entirely on improving security, reliability, and performance. Since then, IIS 6.0 has proven to be a rock-solid Web server, achieving high reliability and security track records with only a single critical security bulletin since its release (which was not exploitable remotely).

The vision for IIS 7.0 was to take the speed, reliability, and security of the IIS 6.0 codebase and turn it into a highly extensible and manageable Web server platform powerful enough to run Web applications of the future. The result is the most ambitious Microsoft Web server yet, delivering the largest number of architectural improvements in the history of IIS.
At the core of the IIS 7.0 release is a completely modular Web server, comprised of more than 40 features that can be assembled into small-footprint Web servers optimized for the desired role in your application topology. These features are built on top of a new extensibility layer that allows developers to extend or replace virtually any aspect of the server, in native code or with the Microsoft® .NET Framework. IIS 7.0 offers extensibility throughout its runtime, management, and operational features to help you build end-to-end solutions for your specific needs. On top of the core platform, IIS 7.0 tackles many of the problems associated with the manageability and operation of the server. It features a brand new configuration system that enables fully delegated management of sites and finally makes xcopy deployment of Web applications a reality. The new management APIs and diagnostic features make deployment, administration, and troubleshooting of the server significantly easier and more convenient than ever before.

Integration with ASP.NET in IIS 6.0 and IIS 7.0

Integration with ASP.NET in IIS 6.0 and IIS 7.0


Stopwatch Class

Provides a set of methods and properties that you can use to accurately measure elapsed time.
A Stopwatch instance can measure elapsed time for one interval, or the total of elapsed time across multiple intervals. In a typical Stopwatch scenario, you call the Start method, then eventually call the Stop method, and then you check elapsed time using the Elapsed property.

A Stopwatch instance is either running or stopped; use IsRunning to determine the current state of a Stopwatch. Use Start to begin measuring elapsed time; use Stop to stop measuring elapsed time. Query the elapsed time value through the properties Elapsed, ElapsedMilliseconds, or ElapsedTicks. You can query the elapsed time properties while the instance is running or stopped. The elapsed time properties steadily increase while the Stopwatch is running; they remain constant when the instance is stopped.

By default, the elapsed time value of a Stopwatch instance equals the total of all measured time intervals. Each call to Start begins counting at the cumulative elapsed time; each call to Stop ends the current interval measurement and freezes the cumulative elapsed time value. Use the Reset method to clear the cumulative elapsed time in an existing Stopwatch instance.

The Stopwatch measures elapsed time by counting timer ticks in the underlying timer mechanism. If the installed hardware and operating system support a high-resolution performance counter, then the Stopwatch class uses that counter to measure elapsed time. Otherwise, the Stopwatch class uses the system timer to measure elapsed time. Use the Frequency and IsHighResolution fields to determine the precision and resolution of the Stopwatch timing implementation.

The Stopwatch class assists the manipulation of timing-related performance counters within managed code. Specifically, the Frequency field and GetTimestamp method can be used in place of the unmanaged Win32 APIs QueryPerformanceFrequency and QueryPerformanceCounter.

private void MyStopWatch(){
string stringToConvert = “1234567890”;
int convertedString = 0;

Stopwatch watch = new Stopwatch();
for (int i = 0; i < 300000000; i++){
convertedString = Convert.ToInt32(stringToConvert);
Console.WriteLine(“Time Elapsed : ” + watch.Elapsed.ToString());

for (int i = 0; i < 300000000; i++){
convertedString = Int32.Parse(stringToConvert);
Console.WriteLine(“Time Elapsed : ” + watch.Elapsed.ToString());

(source: )

Minimizing Deadlocks

Although deadlocks cannot be completely avoided, following certain coding conventions can minimize the chance of generating a deadlock. Minimizing deadlocks can increase transaction throughput and reduce system overhead because fewer transactions are:

  • Rolled back, undoing all the work performed by the transaction.
  • Resubmitted by applications because they were rolled back when deadlocked.

To help minimize deadlocks:

  • Access objects in the same order.
  • Avoid user interaction in transactions.
  • Keep transactions short and in one batch.
  • Use a lower isolation level.
  • Use a row versioning-based isolation level.
    Set READ_COMMITTED_SNAPSHOT database option ON to enable read-committed transactions to use row versioning.
    Use snapshot isolation.
  • Use bound connections.
  • Access Objects in the Same Order

If all concurrent transactions access objects in the same order, deadlocks are less likely to occur. For example, if two concurrent transactions obtain a lock on the Supplier table and then on the Part table, one transaction is blocked on the Supplier table until the other transaction is completed. After the first transaction commits or rolls back, the second continues, and a deadlock does not occur. Using stored procedures for all data modifications can standardize the order of accessing objects.

Avoid User Interaction in Transactions
Avoid writing transactions that include user interaction, because the speed of batches running without user intervention is much faster than the speed at which a user must manually respond to queries, such as replying to a prompt for a parameter requested by an application. For example, if a transaction is waiting for user input and the user goes to lunch or even home for the weekend, the user delays the transaction from completing. This degrades system throughput because any locks held by the transaction are released only when the transaction is committed or rolled back. Even if a deadlock situation does not arise, other transactions accessing the same resources are blocked while waiting for the transaction to complete.


Keep Transactions Short and in One Batch
A deadlock typically occurs when several long-running transactions execute concurrently in the same database. The longer the transaction, the longer the exclusive or update locks are held, blocking other activity and leading to possible deadlock situations.

Use a Lower Isolation Level
Determine whether a transaction can run at a lower isolation level. Implementing read committed allows a transaction to read data previously read (not modified) by another transaction without waiting for the first transaction to complete. Using a lower isolation level, such as read committed, holds shared locks for a shorter duration than a higher isolation level, such as serializable. This reduces locking contention.

Use a Row Versioning-based Isolation Level
When the READ_COMMITTED_SNAPSHOT database option is set ON, a transaction running under read committed isolation level uses row versioning rather than shared locks during read operations.

Snapshot isolation also uses row versioning, which does not use shared locks during read operations. Before a transaction can run under snapshot isolation, the ALLOW_SNAPSHOT_ISOLATION database option must be set ON.

Implement these isolation levels to minimize deadlocks that can occur between read and write operations.

Use Bound Connections
Using bound connections, two or more connections opened by the same application can cooperate with each other. Any locks acquired by the secondary connections are held as if they were acquired by the primary connection, and vice versa. Therefore they do not block each other.


See also: Detecting and Ending Deadlocks
Handling Deadlocks
Using Row Versioning-based Isolation Levels
Using Bound Sessions


A deadlock occurs when two or more tasks permanently block each other by each task having a lock on a resource which the other tasks are trying to lock. For example:

  • Transaction A acquires a share lock on row 1.
  • Transaction B acquires a share lock on row 2.
  • Transaction A now requests an exclusive lock on row 2, and is blocked until transaction B finishes and releases the share lock it has on row 2.
  • Transaction B now requests an exclusive lock on row 1, and is blocked until transaction A finishes and releases the share lock it has on row 1.

Transaction A cannot complete until transaction B completes, but transaction B is blocked by transaction A. This condition is also called a cyclic dependency: Transaction A has a dependency on transaction B, and transaction B closes the circle by having a dependency on transaction A.

Both transactions in a deadlock will wait forever unless the deadlock is broken by an external process. The Microsoft SQL Server Database Engine deadlock monitor periodically checks for tasks that are in a deadlock. If the monitor detects a cyclic dependency, it chooses one of the tasks as a victim and terminates its transaction with an error. This allows the other task to complete its transaction. The application with the transaction that terminated with an error can retry the transaction, which usually completes after the other deadlocked transaction has finished.

Using certain coding conventions in applications reduces the chance that applications will cause deadlocks. For more information, see Minimizing Deadlocks.

Deadlocking is often confused with normal blocking. When a transaction requests a lock on a resource locked by another transaction, the requesting transaction waits until the lock is released. By default, SQL Server transactions do not time out, unless LOCK_TIMEOUT is set. The requesting transaction is blocked, not deadlocked, because the requesting transaction has not done anything to block the transaction owning the lock. Eventually, the owning transaction will complete and release the lock, and then the requesting transaction will be granted the lock and proceed.

Deadlocks are sometimes called a deadly embrace.

Deadlock is a condition that can occur on any system with multiple threads, not just on a relational database management system, and can occur for resources other than locks on database objects. For example, a thread in a multithreaded operating system might acquire one or more resources, such as blocks of memory. If the resource being acquired is currently owned by another thread, the first thread may have to wait for the owning thread to release the target resource. The waiting thread is said to have a dependency on the owning thread for that particular resource. In an instance of the Database Engine, sessions can deadlock when acquiring nondatabase resources, such as memory or threads.

Deadlocks can also occur when a table is partitioned and the LOCK_ESCALATION setting of ALTER TABLE is set to AUTO. When LOCK_ESCALATION is set to AUTO, concurrency increases by allowing the Database Engine to lock table partitions at the HoBT level instead of at the TABLE level. However, when separate transactions hold partition locks in a table and want a lock somewhere on the other transactions partition, this causes a deadlock. This type of deadlock can be avoided by setting LOCK_ESCALATION to TABLE; although this setting will reduce concurrency by forcing large updates to a partition to wait for a table lock.