مطالب دوره‌ها
استفاده از Adobe iFilter برای جستجوی Full Text در فایل‌های PDF
در قسمت‌های قبل، نحوه‌ی کار با فیلترهای FTS آفیس را بررسی کردیم. شرکت Adobe نیز برای جستجوی Full-Text بر روی فایل‌های PDF، یک iFilter خاص را طراحی کرده‌است که نسخه‌ی آخر آن‌را از آدرس ذیل می‌توانید دریافت کنید:
یک تجربه‌ی مهم: نگارش 11 آن را با SQL Server X64 تست کردم کار نکرد. اما نگارش 9 کار می‌کند.
مستندات کامل


پس از نصب ابتدایی آن، مراحل ذیل را برای فعال سازی آن باید طی کرد:

1) تنظیم مسیر پوشه bin نصب فیلتر (مهم!)
 Start > Control Panel > System > Advanced
Environment Variables -> System Variables -> find PATH
مسیر فوق را در تنظیمات ویندوز یافته و سپس به انتهای Path، آدرس پوشه bin فیلتر نصب شده را اضافه کنید:
 C:\Program Files\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin\
دقت داشته باشید که این مسیر باید به \ ختم شود.
سپس کل سیستم را ری استارت کنید.


2) ثبت آن در وهله‌ی جاری SQL Server
برای این منظور ابتدا دستورات ذیل را جرا کنید:
 exec sys.sp_fulltext_service 'load_os_resources', 1;
EXEC sp_fulltext_service 'verify_signature', 0
EXEC sp_fulltext_service 'update_languages'; -- update language list
EXEC sp_fulltext_service 'restart_all_fdhosts'; -- restart daemon
reconfigure with override
گزینه‌ی verify_signature مربوط به فایل‌های iFilter ایی است که امضای دیجیتال ندارند.
سپس در management studio یکبار بر روی وهله‌ی جاری کلیک راست کرده و گزینه‌ی Restart را انتخاب کنید (مهم).

3) پس از ری‌استارت SQL Server، اطمینان حاصل کنید که این فیلتر جدید نصب شده‌است:
 exec sys.sp_help_fulltext_system_components 'filter';


و یا کوئری ذیل نیز برای این منظور مفید است:
 SELECT document_type, path from sys.fulltext_document_types where document_type = '.pdf'

4) در ادامه برای استفاده از آن آزمایش ذیل را ترتیب خواهیم داد.

ایجاد یک جدول جدید که فایل‌های باینری PDF را در خود ذخیره می‌کند:
 CREATE TABLE PdfDocuments
(
id INT IDENTITY(1,1) NOT NULL,
doctype NCHAR(4) NOT NULL,
doccontent VARBINARY(MAX) NOT NULL,
CONSTRAINT PK_PdfDocuments
PRIMARY KEY CLUSTERED(id)
);
ستون‌های doctype معرف نوع سند و doccontent ذخیره کننده‌ی محتوای کامل فایل‌های PDF خواهند بود.
سپس چند رکورد را در آن ثبت می‌کنیم. برای نمونه دو مقاله‌ی خروجی PDF سایت جاری را در این جدول ثبت خواهیم کرد:
 INSERT INTO PdfDocuments(doctype, doccontent)
SELECT
N'PDF',
bulkcolumn FROM OPENROWSET (BULK 'C:\Users\Vahid\Downloads\1732-DotNetTips.pdf', SINGLE_BLOB) AS doc;

INSERT INTO PdfDocuments(doctype, doccontent)
SELECT
N'PDF',
bulkcolumn FROM OPENROWSET (BULK 'C:\Users\Vahid\Downloads\1733-DotNetTips.pdf', SINGLE_BLOB) AS doc;
در ادامه علاقمندیم تا بر روی خواص و متادیتای فایل‌های PDF نیز بتوانیم جستجوی FTS انجام دهیم. به همین منظور search propery list متناظری را نیز تعریف خواهیم کرد. همانطور که در قسمت‌های قبل عنوان شد، نیاز است GUID هر خاصیت را برای تعریف از سازنده‌ی iFilter دریافت کرد. این اطلاعات در سند ذیل مستند شده‌اند:

 -- Search property list
CREATE SEARCH PROPERTY LIST PdfSearchPropertyList;
GO
ALTER SEARCH PROPERTY LIST PdfSearchPropertyList
ADD 'Author'
WITH (PROPERTY_SET_GUID = 'F29F85E0-4FF9-1068-AB91-08002B27B3D9',
PROPERTY_INT_ID = 4,
PROPERTY_DESCRIPTION = 'Author - author of a given item.');
GO

در اینجا اگر علاقمند بودید، stop list معرفی شده در قسمت‌های قبل را نیز می‌توان افزود.
 CREATE FULLTEXT STOPLIST SQLStopList;
GO
-- Add a stopwords
ALTER FULLTEXT STOPLIST SQLStopList ADD N'به' LANGUAGE 'English';
ALTER FULLTEXT STOPLIST SQLStopList ADD N'با' LANGUAGE 'English';
--.....

سپس یک کاتالوگ FTS و ایندکس Full-Text ایی را بر روی این جدول ایجاد می‌کنیم:
 -- Full-text catalog
CREATE FULLTEXT CATALOG PdfDocumentsFtCatalog;
GO

-- Full-text index
CREATE FULLTEXT INDEX ON PdfDocuments
(
  [doccontent] TYPE COLUMN [doctype]
  Language 1033
  STATISTICAL_SEMANTICS
)
KEY INDEX PK_PdfDocuments
ON PdfDocumentsFtCatalog
WITH STOPLIST = SQLStopList,
  SEARCH PROPERTY LIST = PdfSearchPropertyList,
  CHANGE_TRACKING AUTO;
GO

آیا کار می‌کند ؟ چیزی ایندکس شده‌است؟
 SELECT
 I.document_id,
 I.display_term,
 I.occurrence_count
FROM sys.dm_fts_index_keywords_by_document(DB_ID(DB_NAME()), OBJECT_ID(N'dbo.PdfDocuments')) AS I
INNER JOIN dbo.PdfDocuments D
ON D.id = I.document_id;


انجام دو کوئری بر روی آن. یکی برای یافتن متنی ساده و دیگری برای یافتن خواص

 SELECT *
FROM PdfDocuments
WHERE CONTAINS(doccontent, N'است')

SELECT
 I.document_id,
 I.display_term,
 I.property_id
FROM sys.dm_fts_index_keywords_by_property(DB_ID(DB_NAME()), OBJECT_ID(N'dbo.PdfDocuments')) AS I
INNER JOIN dbo.PdfDocuments D
ON D.id = I.document_id;


 
مطالب
تزریق وابستگی‌ها در پروفایل‌های AutoMapper در برنامه‌های ASP.NET Core
Profileهای AutoMapper، قابلیت تزریق وابستگی‌ها را در سازنده‌ی خود ندارند؛ به همین جهت در این مطلب، دو راه حل را جهت رفع این محدودیت بررسی می‌کنیم.


مثال: نیاز به نگاشت کلمه‌ی عبور، به کلمه‌ی عبور هش شده

فرض کنید موجودیت کاربری که قرار است در بانک اطلاعاتی ذخیره شود، چنین ساختاری را دارد:
namespace AutoMapperInjection.Entities
{
    public class User
    {
        public int Id { set; get; }

        public string HashedPassword { set; get; }
    }
}
در اینجا کلمه‌ی عبور، به صورت معمولی ذخیره نمی‌شود و معادل هش شده‌ی آن ذخیره خواهد شد. اما اطلاعاتی را که از کاربر دریافت می‌کنیم:
namespace AutoMapperInjection.Models
{
    public class UserDto
    {
        public string Password { set; get; }
    }
}
حاوی کلمه‌ی عبور معمولی است که باید در حین نگاشت UserDto به User، هش شود. این اطلاعات نیز به صورت زیر توسط اکشن متد RegisterUser دریافت می‌شوند که توسط متد mapper.Map، قرار است به یک نمونه از شیء User تبدیل شود:
namespace AutoMapperInjection.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class HomeController : ControllerBase
    {
        private readonly IMapper _mapper;

        public HomeController(IMapper mapper)
        {
            _mapper = mapper ?? throw new NullReferenceException(nameof(mapper));
        }

        [HttpPost("[action]")]
        public IActionResult RegisterUser(UserDto model)
        {
            var user = _mapper.Map<User>(model);

            // TODO: Save user

            return Ok();
        }
    }
}
کار این هش شدن نیز برای مثال توسط سرویس زیر انجام می‌شود:
using System;
using System.Security.Cryptography;
using System.Text;

namespace AutoMapperInjection.Services
{
    public interface IPasswordHasherService
    {
        string GetSha256Hash(string input);
    }

    public class PasswordHasherService : IPasswordHasherService
    {
        public string GetSha256Hash(string input)
        {
            using var hashAlgorithm = new SHA256CryptoServiceProvider();
            var byteValue = Encoding.UTF8.GetBytes(input);
            var byteHash = hashAlgorithm.ComputeHash(byteValue);
            return Convert.ToBase64String(byteHash);
        }
    }
}
به همین جهت در حین تعریف نگاشت‌های AutoMaper، نیاز خواهیم داشت تا بتوانیم از این سرویس استفاده کنیم.


روش اول: IValueResolver‌ها قابلیت تزریق وابستگی را در سازنده‌ی خود دارند

توسط یک IValueResolver سفارشی، می‌توانیم مشخص کنیم که برای مثال اطلاعات یک خاصیت خاص، چگونه باید از منبع دریافتی تامین شود:
        public class HashedPasswordResolver : IValueResolver<UserDto, User, string>
        {
            private readonly IPasswordHasherService _hasher;

            public HashedPasswordResolver(IPasswordHasherService hasher)
            {
                _hasher = hasher ?? throw new ArgumentNullException(nameof(hasher));
            }

            public string Resolve(UserDto source, User destination, string destMember, ResolutionContext context)
            {
                return _hasher.GetSha256Hash(source.Password);
            }
        }
همانطور که مشاهده می‌کنید، در اینجا می‌توان سرویس مدنظر را به سازنده‌ی این کلاس تزریق کرد و سپس از آن جهت تامین مقدار هش شده‌ی کلمه‌ی عبور استفاده کرد. IValueResolverها تنها تامین کننده‌ی مقدار یک خاصیت، در حین نگاشت هستند.

پس از آن، روش استفاده‌ی از این تامین کننده‌ی مقدار سفارشی، به صورت زیر است:
    public class UserDtoMappingsProfile : Profile
    {
        public UserDtoMappingsProfile()
        {
            // Map from User (entity) to UserDto, and back
            this.CreateMap<User, UserDto>()
                .ReverseMap()
                .ForMember(user => user.HashedPassword, exp => exp.MapFrom<HashedPasswordResolver>());
        }
    }
با این تعاریف، هر زمانیکه قرار است کار var user = _mapper.Map<User>(model) انجام شود، مقدار خاصیت HashedPassword، از طریق HashedPasswordResolver تامین می‌شود که در اینجا کار تزریق وابستگی‌های آن نیز به صورت خودکار توسط AutoMapper مدیریت می‌شود. البته بدیهی است که سرویس IPasswordHasherService باید به نحو زیر پیشتر به سیستم معرفی شده باشد:
namespace AutoMapperInjection
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddScoped<IPasswordHasherService, PasswordHasherService>();
            services.AddAutoMapper(typeof(UserDtoMappingsProfile).Assembly);
            services.AddControllers();
        }


روش دوم: IMappingAction‌ها قابلیت تزریق وابستگی را در سازنده‌ی خود دارند

می‌توان پیش و یا پس از عملیات نگاشت، منطقی را توسط یک IMappingAction سفارشی بر روی آن اجرا کرد که در اینجا نیز امکان تزریق وابستگی در سازنده‌ی IMappingActionهای پیاده سازی شده، وجود دارد:
        public class UserDtoMappingsAction : IMappingAction<UserDto, User>
        {
            private readonly IPasswordHasherService _hasher;

            public UserDtoMappingsAction(IPasswordHasherService hasher)
            {
                _hasher = hasher ?? throw new ArgumentNullException(nameof(hasher));
            }

            public void Process(UserDto source, User destination, ResolutionContext context)
            {
                destination.HashedPassword = _hasher.GetSha256Hash(source.Password);
            }
        }
در اینجا می‌خواهیم مقدار یک یا چندین خاصیت از مقصد نگاشت را (شیء User در اینجا) پس از نگاشت ابتدایی از طریق مقدار دریافتی از کاربر، با منطق خاصی تغییر دهیم. برای مثال کلمه‌ی عبور ساده‌ی دریافتی را هش کنیم و به خاصیت خاصی نسبت دهیم (و یا حتی مقدار خواص دیگری را نیز پس از نگاشت، تغییر دهیم).

در این حالت روش استفاده‌ی از کلاس UserDtoMappingsAction به صورت زیر است:
    public class UserDtoMappingsProfile : Profile
    {
        public UserDtoMappingsProfile()
        {
            // Map from User (entity) to UserDto, and back
            this.CreateMap<User, UserDto>()
                .ReverseMap()
                .AfterMap<UserDtoMappingsAction>();
        }
    }


کدهای کامل این مطلب را از اینجا می‌توانید دریافت کنید: AutoMapperInjection.zip
مطالب
از سرگیری مجدد، لغو درخواست و سعی مجدد دریافت فایل‌های حجیم توسط HttpClient
پس از آشنایی با «نکات دریافت فایل‌های حجیم توسط HttpClient»، در ادامه می‌توان سه قابلیت مهم از سرگیری مجدد، لغو درخواست و سعی مجدد دریافت فایل‌های حجیم را با HttpClient، همانند برنامه‌های download manager نیز پیاده سازی کرد.


از سرگیری مجدد درخواست ارسالی توسط HttpClient

یک نمونه از سرگیری مجدد درخواست را در مطلب «اضافه کردن قابلیت از سرگیری مجدد (resume) به HttpWebRequest» پیشتر در این سایت مطالعه کرده‌اید. اصول کلی آن نیز در اینجا صادق است. HTTP 1.1 از مفهوم range headers‌، برای دریافت پاسخ‌های جزئی پشتیبانی می‌کند. به این ترتیب در صورت پیاده سازی چنین قابلیتی در برنامه‌ی سمت سرور، می‌توان دریافت بازه‌ای از بایت‌ها را بجای دریافت فایل از ابتدا، از سرور درخواست کرد. به یک چنین قابلیتی Resume و یا از سرگیری مجدد گرفته می‌شود و درحین دریافت فایل‌های حجیم بسیار حائز اهمیت است.
var fileInfo = new FileInfo(outputFilePath);
long resumeOffset = 0;
if (fileInfo.Exists)
{
    resumeOffset = fileInfo.Length;
}
if (resumeOffset > 0)
{
    _client.DefaultRequestHeaders.Range = new RangeHeaderValue(resumeOffset, null);
}
در اینجا نحوه‌ی تنظیم یک RangeHeader را مشاهده می‌کنید. ابتدا نیاز است بررسی کنیم آیا فایل دریافتی از پیش موجود است؟ آیا قسمتی از این درخواست پیشتر دریافت شده و محتوای آن هم اکنون به صورت ذخیره شده وجود دارد؟ اگر بله، درخواست دریافت این فایل را بر اساس اندازه‌ی دریافتی فعلی آن، به سرور ارائه می‌کنیم.

یک نکته: تمام وب سرورها و یا برنامه‌های وب از یک چنین قابلیتی پشتیبانی نمی‌کنند.
روش تشخیص آن نیز به صورت زیر است:
var response = await client.GetAsync(url, HttpCompletionOption.ResponseHeadersRead);
if (response.Headers.AcceptRanges == null && resumeOffset > 0)
{
    // resume not supported, starting over
}
پس از خواندن هدر درخواست، اگر خاصیت AcceptRanges آن نال بود، یعنی قابلیت از سرگیری مجدد را ندارد. در این حالت باید فایل موجود فعلی را حذف و یا از نو (FileMode.CreateNew) بازنویسی کرد (بجای حالت FileMode.Append).


لغو درخواست ارسالی توسط HttpClient

پس از شروع غیرهمزمان client.GetAsync می‌توان متد CancelPendingRequests آن‌را فراخوانی کرد تا کلیه درخواست‌های مرتبط با این client لغو شوند. اما این متد صرفا برای حالت پیش‌فرض client.GetAsync که دریافت هدر + محتوا است کار می‌کند (یعنی حالت HttpCompletionOption.ResponseContentRead). اگر همانند نکات بررسی شده‌ی در مطلب «دریافت فایل‌های حجیم توسط HttpClient» صرفا درخواست خواندن هدر را بدهیم (HttpCompletionOption.ResponseHeadersRead)، چون کنترل ادامه‌ی بحث را خودمان بر عهده گرفته‌ایم، لغو آن نیز به عهده‌ی خودمان است و متد CancelPendingRequests بر روی آن تاثیر نخواهد داشت.
این نکته در مورد تنظیم خاصیت TimeOut نیز صادق است. این خاصیت فقط زمانیکه دریافت کل هدر + محتوا توسط متد GetAsync مدیریت شوند، تاثیر گذار است.
بنابراین درحالتیکه نیاز به کنترل بیشتر است، هرچند فراخوانی متد CancelPendingRequests ضرری ندارد، اما الزاما سبب قطع کل درخواست نمی‌شود و باید این لغو را به صورت ذیل پیاده سازی کرد:
ابتدا یک منبع توکن لغو عملیات را به صورت ذیل ایجاد می‌کنیم:
private readonly CancellationTokenSource _cts = new CancellationTokenSource();
سپس، متد لغو برنامه، تنها کافی است متد Cancel این cts را فراخوانی کند؛ تا عملیات دریافت فایل خاتمه یابد.
پس از این فراخوانی (()cts.Cancel)، نحوه‌ی واکنش به آن به صورت ذیل خواهد بود:
var result = await client.GetAsync(url, HttpCompletionOption.ResponseHeadersRead, _cts.Token);
using(var stream = await result.Content.ReadAsStreamAsync())
{
   byte[] buffer = new byte[80000];
   int bytesRead;
   while((bytesRead = await stream.ReadAsync(buffer, 0, buffer.Length)) > 0 &&
         !_cts.IsCancellationRequested)
   {
      outputStream.Write(buffer, 0, bytesRead);
   }
}
در اینجا از cts.Token به عنوان پارامتر سوم متد GetAsync استفاده شده‌است. همچنین قسمت ثبت اطلاعات دریافتی، در استریم خروجی نیز به صورت یک حلقه درآمده‌است تا بتوان خاصیت IsCancellationRequested این توکن لغو را بررسی کرد و نسبت به آن واکنش نشان داد.


سعی مجدد درخواست ارسالی توسط HttpClient

یک روش پیاده سازی سعی مجدد درخواست شکست خورده، توسط کتابخانه‌ی Polly است. روش دیگر آن نیز به صورت ذیل است:
public async Task DownloadFileAsync(string url, string outputFilePath, int maxRequestAutoRetries)
{
            var exceptions = new List<Exception>();

            do
            {
                --maxRequestAutoRetries;
                try
                {
                    await doDownloadFileAsync(url, outputFilePath);
                }
                catch (TaskCanceledException ex)
                {
                    exceptions.Add(ex);
                }
                catch (HttpRequestException ex)
                {
                    exceptions.Add(ex);
                }
                catch (Exception ex) when (isNetworkError(ex))
                {
                    exceptions.Add(ex);
                }

                // Wait a bit and try again later
               if (exceptions.Any())  await Task.Delay(2000, _cts.Token);
            } while (maxRequestAutoRetries > 0 &&
                     !_cts.IsCancellationRequested);

            var uniqueExceptions = exceptions.Distinct().ToList();
            if (uniqueExceptions.Any())
            {
                if (uniqueExceptions.Count() == 1)
                    throw uniqueExceptions.First();
                throw new AggregateException("Could not process the request.", uniqueExceptions);
            }
}

private static bool isNetworkError(Exception ex)
{
    if (ex is SocketException || ex is WebException)
        return true;
    if (ex.InnerException != null)
        return isNetworkError(ex.InnerException);
    return false;
}
در اینجا متد doDownloadFileAsync، پیاده سازی همان متدی است که در قسمت «لغو درخواست ارسالی توسط HttpClient» در مورد آن بحث شد. این قسمت دریافت فایل را در یک حلقه که حداقل یکبار اجرا می‌شود، قرار می‌دهیم. متد GetAsync استثناءهایی مانند TaskCanceledException (در حین TimeOut و یا فراخوانی متد CancelPendingRequests که البته همانطور که توضیح داده شد، بر روی روش کنترل Response تاثیری ندارند)، HttpRequestException پس از فراخوانی متد response.EnsureSuccessStatusCode (جهت اطمینان حاصل کردن از دریافت پاسخی بدون مشکل از طرف سرور) و یا SocketException و WebException را درصورت بروز مشکلی در شبکه، صادر می‌کند. نیازی به بررسی سایر استثناءها در اینجا نیست.
اگر یکی از این استثناءهای یاد شده رخ‌دادند، اندکی صبر کرده و مجددا درخواست را از ابتدا صادر می‌کنیم.
در پایان این سعی‌های مجدد، اگر استثنایی ثبت شده بود و همچنین عملیات نیز با موفقیت به پایان نرسیده بود، آن‌را به فراخوان صادر می‌کنیم.
نظرات مطالب
فعال سازی عملیات CRUD در Kendo UI Grid
- فایل NuGet.targets را باز کنید. مقدار تنظیم شده‌ی ذیل را در آن خواهید یافت:
 <DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
به این معنا که اگر فایل nuget.exe وجود نداشت، از اینترنت دریافتش کن.
همچنین مخزن کد مثال‌های این سری، حاوی این فایل هست و بهتر است از این مخزن کد استفاده کنید، چون حاوی مثال‌های به روز شده‌ی این سری هست که در انتهای بحث‌ها پیوست نشده‌اند.
- تعریف فیلدها و ستون‌ها در سمت کاربر به اختیار شما است و هیچ ضرورتی ندارد که با تعداد فیلدهای سمت سرور یکی باشد. حتی می‌توانید ستون محاسبه شده‌ هم ایجاد کنید.
- در مورد ارسال تصویر مطلب جداگانه‌ای در سایت تهیه شده‌است؛ در اینجا
نظرات مطالب
ایندکس منحصر به فرد با استفاده از Data Annotation در EF Code First
از چه دیتابیسی استفاده می‌کنید؟ اگر SQL Server است که تا قبل از نگارش 2008 آن چنین اجازه‌ای رو به شما نمی‌ده تا یک فیلد منحصربفرد نال پذیر داشته باشید. اگر 2008 به بعد است، باید ایندکس فیلتر شده برای اینکار تعریف کنید. مثلا:
create unique nonclustered index idx on dbo.DimCustomer(emailAddress)
where EmailAddress is not null;
اطلاعات بیشتر اینجا و اینجا
بر همین مبنا باید قسمت ADD CONSTRAINT متد ExecuteUniqueIndexes را در صورت نیاز بازنویسی کنید.
نظرات مطالب
اجرای وظایف زمان بندی شده با Quartz.NET - قسمت دوم
همانطور که عنوان شد طراحی دیتابیس است نه استفاده از ابزارهای جانبی. یک وبلاگ در این حالت شبیه به کوئری زیر کار می‌کند (هر فراخوانی صفحه‌ای معادل است با یک کوئری از بانک اطلاعاتی):
select * from tblPosts where (showDate is null) or (showDate<=getdate())
فیلد showDate اگر نال بود، یعنی یک مطلب معمولی است که درجا نمایش پیدا می‌کند. اگر تاریخی برای آن مشخص شده بود، بر اساس تاریخ جاری یک مقایسه صورت گرفته و رکوردها انتخاب و نمایش داده می‌شوند.
نظرات مطالب
مشکل ی و ک فارسی و عربی در یک دیتابیس اس کیوال سرور
اثبات این مدعا هم که مشکل از SQL Server نیست ساده است (فیلد با collation عربی ایجاد شده و ی فارسی در آن ثبت شده است و سپس گزارشگیری):
DECLARE @tbl AS TABLE (f1 NVARCHAR(50) COLLATE Arabic_CI_AS NULL)
INSERT INTO @tbl(f1) VALUES(NCHAR(1740))
SELECT * FROM @tbl
مطالب
برنامه نویسی موازی - بخش اول - مفاهیم

برنامه نویسی موازی، نقطه‌ی متقابل برنامه نویسی سریال که حتی گاها با برنامه نویسی سریال به سبک Asynchronous به اشتباه گرفته می‌شود، به سبکی از برنامه نویسی گفته می‌شود که در آن برنامه نویس قابلیت اجرای بخش‌های موازی برنامه را از طریق چندین Thread و به طور همزمان ایجاد کرده باشد. نکاتی که در این سبک برنامه نویسی بسیار مهم است، مهارت‌های برنامه نویس در درک قسمت‌های موازی برنامه و مجزا سازی این بخش‌ها از یکدیگر است تا کمترین ارتباط را با هم داشته باشند. مشخصا تمامی یک برنامه قابلیت موازی سازی را نخواهد داشت؛ اما مفهومی به عنوان درجه‌ی موازی سازی در هر برنامه وجود دارد که ایده آل موازی سازی، رسیدن به این درجه‌ی از موازی سازی است.
در برنامه نویسی موازی، قسمت‌هایی از برنامه که به Thread‌های مجزایی برای اجرا محول شده‌اند، می‌توانند تقریبا در یک زمان شروع به اجرا کنند و اینگونه است که سرعت اجرای عملیات افزایش پیدا می‌کند. به عنوان مثال فرض کنید برنامه‌ای داریم که ۱۰۰ رکورد از پایگاه داده واکشی می‌کند و بررسی‌ای بر روی یکی از فیلدهای آن انجام می‌دهد که ۳ ثانیه زمان گیر است و در صورت وجود شرایط خاصی، آن رکورد را لاگ می‌کند. در برنامه نویسی سریال، برسی ۱۰۰ رکورد، به ۳۰۰ ثانیه زمان برای انجام احتیاج دارد؛ ولی با فرض انجام همین عملیات با دو Thread به صورت موازی، این زمان تقریبا به نصف کاهش پیدا خوهد کرد.


چرا و در چه زمانی باید به سراغ برنامه نویسی موازی رفت !؟


نرم افزارهای بزرگ با تعداد تراکنش‌های بالا و حجم اطلاعات بالا که همواره نیازمند پردازش مستمر هستند، لزوم استفاده‌ی بهینه از قدرت پردازشی پردازنده‌ها را ایجاب می‌کنند. به طور کل می‌توان گفت قسمت‌هایی از برنامه که عملیات پردازشی را روی داده‌های مجزا انجام می‌دهند، بهترین بخش برای انجام عملیات به صورت موازی و همزمان هستند. البته نباید این نکته را نیز فراموش کرد که عملیات ایجاد Thread و مدیریت آن‌ها، دارای سربار است. ازین‌رو بهتر است برای کارهای ساده و کوچک، به سراغ برنامه نویسی موازی نرفت.


در اجرای موازی بخش‌های مختلف برنامه، ترتیب انجام هر بخش نباید در نتیجه‌ی کلی تاثیر گذار باشد. در عملیات جمع یک مجموعه می‌توان آن را به چند Thread مجزا محول کرد تا هر بخش از مجموعه را یک Thread جمع بزند و در نهایت نتیجه‌ی کل Thread‌ها با هم جمع شود. در این عملیات ترتیب اتمام کار هر Thread، نتیجه‌ای بر Thread‌های دیگر و نتیجه‌ی نهایی، نخواهد داشت. اما در شکل بالا بعد از اتمام انجام عملیات تبدیل حروف کوچک به بزرگ توسط هر Thread، گارانتی‌ای برای چاپ آنها به همان ترتیبی که از سورس خوانده شده‌اند، وجود ندارد. به عبارتی ممکن است در ابتدا وظیفه‌ی 2 Thread تمام شده باشد و بعد 1 Thread که باعث خواهد شد در خروجی، ابتدا کاراکترهای "CD" و سپس "AB"  نمایش داده شود. البته این یک مثال ساده برای درک موضوع است.


مفهوم Thread Safe

Thread Safe یک مفهوم مرتبط به زبان‌های برنامه نویسی با قابلیت اجرای چند ریسمانی می‌باشد؛ بدین مفهوم که Thread safe فقط در نرم افزارهایی که به صورت Multi Thread نوشته شده‌اند معنا پیدا می‌کند.
درک مفهوم Thread Safe و تکنیک‌های مرتبط با آن، در نرم افزار‌های چند ریسمانی بسیار حائز اهمیت می‌باشد. چرا که باعث بروز برخی خطاهای منطقی در عملکرد سیستم خواهد شد که بعضاً ردگیری آن‌ها نیز بسیار دشوار است. به طور کلی هنگامیکه thread‌‌های مختلفی در یک برنامه در حال کار همزمان می‌باشند، رخ دادن دو اتفاق شایع زیر دور از ذهن نیست:


1- Dead Lock

مفهوم بن بست در علوم کامپیوتر، یکی ار رایج‌ترین مفاهیم است که از سطح سیستم عامل تا سیستم‌های توزیع شده، تعمیم داده می‌شود. Dead Lock  زمانی رخ می‌دهد که Thread‌های مختلف، با منابع مشترکی کار می‌کنند. بدین صورت که Thread شماره ۱، منبع A را در اختیار دارد و منتظر منبع B است. همزمان Thread شماره دو، منبع B را در اختیار دارد و منتظر منبع A است. به این شرایط، بن بست می‌گویند. شبیه سازی این اتفاق را در کد #C زیر می‌توانید ببینید:
public static void Function_A()
{
 lock (resource_1)
 {
   Thread.Sleep(1000);
   lock (resource_ 2)
   {
   }
 }
}

public static void Function_B()
{
 lock (resource_2)
 {
   Thread.Sleep(1000);
   lock (resource_1)
   {
   }
 }
}

static void Main()
{
  Thread thread_A = new Thread((ThreadStart)Function_A);
  Thread thread_B = new Thread((ThreadStart)Function_B);

  thread_A.Start();
  thread_B.Start();

  while (true)
  {
   // Stare at the two threads in deadlock.
  }
}

2- Race conditions

زمانی رخ می‌دهد که دو یا چند thread به یک مقدار مشترک دسترسی داشته باشند و تلاش کنند که در یک زمان، مقدار آن را تغییر دهند. مشکل از جایی رخ می‌دهد که شما به عنوان یک برنامه نویس نمی‌دانید، در یک زمان یکسان، برای تغییر یه مقدار مشترک بین thread‌ها، اولویت با کدام thread است. این اولویت بندی و جابجایی بین threadها وظیفه‌ی الگوریتم زمان بندی thread‌ها است که در هر زمان می‌تواند بین thread‌های مختلف سوییچ کند. این اولویت بندی می‌تواند روی عملکرد کد شما تاثیر گذار باشد؛ مخصوصا در بخش‌هایی که مقدار مشترکی برسی می‌شوند؛ مانند مثال زیر:
if (x == 5) 
{
   y = x * 2; 
}

اگر بلافاصله بعد از بررسی مقدار متغیر x توسط یک thread ،thread دیگری این مقدار را تغییر دهد، دیگر نتیجه‌ی این بلاک کد، منطقی نخواهد بود و جواب، ۱۰ نخواهد شد.

با توجه به مفاهیم عنوان شده، بررسی Thread safe بودن یک کد، با معیارهای زیر انجام می‌شود:
۱- قفل گذاری روی منابع باید به شکلی باشد که باعث بروز Dead Lock نشود.
۲- استفاده از مقادیر مشترک باید به گونه‌ای باشد که منجر به Race-conditions نشود.

حال اگر در هر برنامه، مقادیر مشترکی بین thread‌‌ها وجود داشته باشد، چه از نوع struct, class, static و ...  باید به این نکته توجه کرد که ذاتا این مقادیر Thread Safe هستند یا نه !؟ در بخش بعدی، راهکارهای قفل گذاری را برای استفاده از مقادیری که ذاتا thread safe نیستند، بررسی می‌کنیم.
نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
با تشکر از مطلب شما.
بنده در پروژه ای دقیقا طبق موارد توضیح داده شده در این مقاله (و سایر پروژه‌های موجود در سایت جاری) عمل کردم ام . مشکلی که دارم کوکی مربوطه موجود می‌باشد (با استفاده از فایبر باگ چک کردم) ولی کاربر در کمتر از ده دقیقه کاربر خارج میشود در صورتی که کوکی هنوز معتبر و زمان منقضی شدن آن به اتمام نرسیده است . تنظیمات به صورت خلاصه به صورت زیر می‌باشد :
   app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString("/Account/Login"),
                 ExpireTimeSpan = TimeSpan.FromDays(30),
                Provider = new CookieAuthenticationProvider
                {
                    OnValidateIdentity = StoreObjectFactory.Container.GetInstance<IApplicationUserManagerService>().OnValidateIdentity()
                },
                SlidingExpiration = true,
                CookieName = "iasaccount"
            });

  public Func<CookieValidateIdentityContext, Task> OnValidateIdentity()
        {
            return SecurityStampValidator.OnValidateIdentity<ApplicationUserManagerService, User, Guid>(
                         validateInterval: TimeSpan.FromDays(3),
                         regenerateIdentityCallback: (manager, user) => GenerateUserIdentityAsync(manager, user),
                         getUserIdCallback: id => id.GetGuidUserId());
        }

و :
            var result = await _signInManagerService.PasswordSignInAsync(loginViewModel.Email, loginViewModel.Password, loginViewModel.RememberMe, shouldLockout: false);

آیا تنظیمات دیگه ای لازم هست که انجام شود ؟
مطالب
آشنایی با FileTable در SQL Server 2012 بخش 2
ستون دیگر stream_id نام دارد که از نوع uniqueidentifier ROWGUIDCOL است. همان‌گونه که در یاد دارید، در FileStream نیز ناگزیر به تعریف چنین ستونی بودیم. بنابراین FileTable استثناء نیست و در این‌جا نیست چنین فیلدی توسط SQL Server تعریف می‌شود. اگر فایل‌ها و پوشه‌ها جابه‌جا نمی‌شدند می‌توانستید از هر دو ستون path_locator یا stream_id برای شناسایی یک رکورد از جدول بهره ببرید. ولی با جابه‌جایی یک فایل و یا به عبارت دیگر تغییر پدر آن در ساختار سلسله‌مراتبی، مقدار path_locator نیز تغییر می‌کند، پس ناگزیر به استفاده از این ستون برای ارجاع به یک ردیف در جدول هستیم.
هر ردیف از جدول نمایان‌گر یک فایل یا پوشه است، بنابراین به ستونی نیاز داریم که بتوانیم این موضوع را نشان دهیم. بر این پایه از ستون is_directory بهره می‌بریم که 1 بودن آن نشان‌دهنده‌ی این است که این ردیف از جدول به یک پوشه ارجاع دارد.
نام فایل یا پوشه در ستونی به نام name نگه‌داری می‌شود که رشته‌ای از نوع (nvarchar(255 است. افزون بر این ستون، ستون‌های دیگری نیز در این جدول وجود دارد که ویژگی‌های یک فایل مانند پنهان‏‌بودن، فقط‏‌خواندنی و ... توسط آن توسط آن به دست می‏آید. ستون پسین file_stream نام دارد که برای پوشه‌ها، محتوای آن Null است. علت آن این است که محتوای واقعی فایل در این ستون نگه‌داری می‌شود. در واقع یک (varbinary(max با ویژگی‌های fileStream است که محتوای باینری آن در سیستم فایل NTFS ذخیره می‌شود. مدیریت پشت صحنه‌ی این ستون برعهده‌ی SQL Server است.
افزون بر این 14 ستون، هر FileTable شامل سه ستون محاسباتی به شرح زیر است:

ستون parent_path_locator نتیجه‏‌ی فراخوانی تابع (GetAncestor(1 در ستون path_locator است که جهت به دست آوردن پوشه‏‌ی پدر یک فایل و پوشه استفاده می‏‌شود. ستون file_type که از مقدار رشته‏‌ای ستون name تجزیه شده است، پسوند فایل را برمی‏‌گرداند. و ستون cached_file_size اندازه‌ی بایت ذخیره‏‌شده ستون file_stream  را برمی‏‌گرداند. با این ساختار ثابت در اینجا، هر FileTable هر آن‏چه از File System نیاز دارید در یک پوشه‏ی اشتراکی به شما می‏‌دهد.

این یعنی نمایش بی‏‌واسطه FileTable به هر کاربر یا برنامه. به طوری که برای نمایش یا به‏‌روزرسانی جدول می‌توانید از روش استاندارد I/O مانند کشیدن و رهاکردن با Windows Explorer یا برنامه‏‌نویسی با  System.IO.FileStream  و API‌های ویندوز استفاده کنید. این‏‌چنین:

- ایجاد یک فایل یا پوشه در سیستم فایل  -> افزودن یک ردیف به جدول

- افزودن یک ردیف به جدول -> ایجاد یک فایل یا پوشه در سیستم فایل 

با کپی فایل‌ها در مسیر بالا، به صورت خودکار رکوردهای زیر در جدول PhotoTable در پایگاه‌داده‌ها افزوده می‌شود: 

به طور خلاصه پیش از این برای افزودن به FileStream دو راه کار پیش رو داشتید. یکی استفاده از T-SQL و دیگر sqlFileStream اکنون SQL Server 2012 راه کار سوم را پیشنهاد می‌کند. استفاده از File System در این روش FileStream  به طور خودکار پر می‌شود. 

پیش از ساخت یک FileTable بیان این نکته دارای اهمیت است که با کپی فایل‏‌ها و پوشه‏‌ها هیچ چیز جدیدی به NTFS افزوده نمی‌شود بلکه محتوای فایل به FileStream افزوده می‌شود و SQL Server با بررسی همزمان FileStream و FileTable نمایشی از ردیف‏‌های FileTable به صورت یک پوشه‏‌ی اشتراکی نشان می‌دهد. این نکته پاسخی به این پرسش خواهد بود که آیا با استفاده از FileTable حجم پایگاه‏‌داده‏‌ها دو برابر خواهد شد و در نتیجه دشواری‏‌ها و چالش‏‌های نگه‏داری و پشتیبانی را پیش رو خواهیم داشت!؟ که پاسخ "خیر" خواهد بود. 

ایجاد یک  FileTable

پیش از این در همین تارنما، روش فعال کردن FileStream در SQL Server  را آموزش دیده اید. اگر درست به خاطر داشته باشید، چیزی شبیه به دستورهای زیر بود:

CREATE DATABASE MyFileArchive
ON PRIMARY
(NAME = MyFileArchive_data,
FILENAME = 'C:\Demo\MyFileArchive_data.mdf'),
FILEGROUP FileStreamGroup CONTAINS FILESTREAM
(NAME = PhotoFileLibrary_blobs,
FILENAME = 'C:\Demo\MyFiles')
LOG ON
(NAME = PhotoFileLibrary_log,
FILENAME = 'C:\Demo\MyFileArchive_log.ldf')

FileTable  به FileStream متکی است؛ بر این پایه پیش از ایجاد یک FileTable باید FileStream را روی پایگاه‌داده‌ها فعال کنیم. این کار با یک تعریف درست توسط بند FILEGROUP…CONTAINS FILESTREAM انجام می‌شود. 

برای ایجاد FileTable تنها کافی است که بند WITH FILESTREAM را به دستور CREATE DATABASE بیفزایید. (یا برای فعال‌کردن FileTable روی یک پایگاه‌داده‌ی ساخته شده بند SET FILESTREAM را در دستور ALTER DATABASE  بنویسید.) در این بند، از DIRECTORY_NAME برای نام‌گذاری یک پوشه برای پایگاه‌داده‌ها استفاده می‌کنیم. این پوشه در یک پوشه ریشه به نام SQL Server instance نمایش داده خواهد شد. بخش دوم بند NON_TRANSACTED_ACCESS=FULL  است که دسترسی غیرتراکنشی را فعال می‌کند.  با این کار برای هر FileTable  در پایگاه داده یک زیرپوشه درون پوشه‌ای که به نام DIRECTORY_NAME  نام‌گذاری شده است؛ ساخته می‌شود. 

با توجه به آنچه گفته شد برای ایجاد یک پایگاه‌داده با امکان ساخت FileTable دستورهای زیر را اجرا کنید: 

CREATE DATABASE MyFileArchive
ON PRIMARY
(NAME = MyFileArchive_data,
FILENAME = 'C:\Demo\MyFileArchive_data.mdf'),
FILEGROUP FileStreamGroup CONTAINS FILESTREAM
(NAME = PhotoFileLibrary_blobs,
FILENAME = 'C:\Demo\MyFiles')
LOG ON
(NAME = PhotoFileLibrary_log,
FILENAME = 'C:\Demo\MyFileArchive_log.ldf')
WITH FILESTREAM
(DIRECTORY_NAME='FilesLibrary',
NON_TRANSACTED_ACCESS=FULL)
اکنون برای ساخت یک FileTable درون این پایگاه‌داده‌ها از دستور زیر استفاده کنید:
USE MyFileArchive
GO
CREATE TABLE PhotoTable AS FileTable
GO
توجه داشته باشید که چون ستون‌های FileTable از پیش تعریف شده است؛ ایجاد آن فقط با نوشتن دستور امکان پذیر است و مانند یک Table عادی از محیط کاربری SQL Server نمی‌توان بهره برد. 
در Object Explorer از گره‏‌ی Tables، گره‏‌ی FileTables را باز کنید و روی جدولی که هم‌‏اکنون ساختیم راست‏‌کلیک کنید. با انتخاب گزینه‏‌ی Explore FileTable Directory پنجره‏‌ی زیر بازمی‏‌شود:

دنباله دارد ...