Coding Conventions

Multithreading

Critical sections should be small and predictable

To avoid dead-locks critical sections should be small enough to prove that dead lock is not possible. Critical section should not cover any complicated business task with access to database (for example business action).

Please AVOID below construction:

lock(typeof(TranslateBO))
{
    //Anti-pattern do not put complicated business functions (like get data by key) inside critical section
    transBO.getDataByKey(phraseKey);

    result = transBO.detailData.syPhrase.Find(phraseKey);
    [...]
}

In above example getDataByKey function is used inside critical section. It is NOT possible to prove that this function placed in critical section will never fall into dead-lock. Above example should be fixed with:

transBO.getDataByKey(phraseKey);
lock(typeof(TranslateBO))
{
    result = transBO.detailData.syPhrase.Find(phraseKey);
    [...]
}

Ensure using thread-safe data containers

DataSets are not thread safe. If dataset is shared between threads and there is action which update dataset than any access to such dataset must be synchronized.

static TranslateDataSet translateCache = new TranslateDataSet()

function void updateCache(DataKey phraseKey, string phrase)
{
    lock(typeof(TranslateBO))
    {
        var phraseRow = translateCache.syPhrase.Find(phraseKey);
        if(phraseRow != null)
        {
             phraseRow.Phrase = phrase;
        }
    }

}

If data set is rarely updated than it make sense to use ReaderWriterLockSlim instead standard lock. For example ReaderWriterLockSlim allows to create sections winch allow parallel reading, but when it came to update than parallel reading will be blocked until section with write access is finished. Please follow https://msdn.microsoft.com/library/system.threading.readerwriterlockslim(v=vs.110).aspx