فقط موردی هست اینکه به چه روشی میشه Identity Core رو به Identity Server متصل کرد براساس مستندات ارائه شده در بخش
این نکتهای را که عنوان کردید با استفاده از DNTProfiler بررسی کردم و اصلا چنین چیزی (28 بار فراخوانی) نیست. در پشت صحنه از نسخهی Async متد Find استفاده میشود (در stack trace موجود هست) و حذف آن با متد سادهای که نوشته شده، یک سری از سازوکارهای داخلی ASP.NET Identity را حذف میکند و به صلاح نیست.
اشتراکها
PostgreSQL 17 منتشر شد
PostgreSQL 17 Released — The big one is here. It's the newest major version of Postgres, and it takes a bigger step forward than even v16. Some of what’s new:
- Overhauled memory management for vacuuming, resulting in significantly lower memory usage and running time. More on this here.
- Incremental backup support.
- Faster B-tree index scans.
- MERGE enhancements, including view support.
- New functions to extract elements from UUIDs.
- WAL improvements – up to 2x write throughput on some workloads.
- Improvements to SQL/JSON support, including JSON_TABLE.
- Bulk loading improvements and perf improvements for COPY which gains the ON_ERROR ignore option to ignore errors.
- Identity columns on partitioned tables.
اشتراکها
PVS-Studio 7.27 منتشر شد
ابزار فوقالعادهای است جهت بررسی کیفیت کدها که توسط برادران روسی توسعه داده میشود؛ همانند تمام محصولات باکیفیت jetbrains مانند Rider، ReSharper و غیره که آنها هم در اصل و بنیان، روسی هستند. در این نگارش، عدم سازگاری آن با آخرین نگارش Rider برطرف شده (با آن یکپارچه میشود) و همچنین قابلیت استفاده در VSCode را هم پیدا کردهاست.
اشتراکها
NuGet 2.8.5 منتشر شد
اشتراکها
NET Framework 4.5.3. منتشر شد
در آن RyuJIT به عنوان JIT Compiler جدید پیش فرض سیستمهای 64 بیتی قرار داده شدهاست. همچنین 150 API جدید به همراه به روز رسانی 50 API موجود در آن پیش بینی شدهاند. تغییرات صورت گرفته
این روزها هیچکدام از فناوریهای دسترسی به داده بدون امکان یکپارچگی آنها با سیستمها و روشهای متفاوت caching ، مطلوب شمرده نمیشوند. ایده اصلی caching هم به زبان ساده به این صورت است : فراهم آوردن روشهایی جهت میسر ساختن دسترسی سریعتر به دادههایی که به صورت متناوب در برنامه مورد استفاده قرار میگیرند، بجای مراجعه مستقیم به بانک اطلاعاتی و خواندن اطلاعات از دیسک سخت.
یکی از تفاوتهای مهم NHibernate با اکثر ORM های موجود داشتن دو سطح متفاوت cache است : first level cache & second level cache .
برای نمونه Entity framework (در زمان نگارش این مطلب) تنها first level caching را پشتیبانی میکند و پروایدر توکار و یکپارچهای را جهت second level caching ارائه نمیدهد.
در این قسمت قصد داریم First Level Cache را بررسی کنیم.
سطح اول caching در NHibernate چیست؟
سطح اول caching در تمام ORM هایی که آنرا پشتیبانی میکنند مانند NHibernate ، در طول عمر یک تراکنش تعریف میگردد. در این حالت در طی یک تراکنش و طول عمر یک سشن، دریافت اطلاعات هر رکورد از بانک اطلاعاتی، تنها یکبار انجام خواهد شد؛ صرفنظر از اینکه کوئری دریافت اطلاعات آن چندبار فراخوانی میگردد. یکی از دلایل این روش هم آن است که هیچ دو شیء متفاوتی که هم اکنون در حافظه قرار دارند نباید بیانگر یک رکورد واحد از بانک اطلاعاتی باشند.
در NHibernate به صورت پیش فرض هر زمانیکه از شیء استاندارد session استفاده میکنید، سطح اول caching نیز فعال است. درست در زمانیکه سشن خاتمه مییابد، این سطح از caching نیز به صورت خودکار تخلیه خواهد گردید.
به first level caching اصطلاحا thought-out cache system یا Cache Through pattern و یا identity map هم گفته میشود.
مثال:
روش متداول و استاندارد کار با NHibernate عموما به صورت زیر است:
الف) دریافت شیء Session از Session Factory
ب) شروع یک تراکنش با فراخوانی متد BeginTransaction شیء Session
ج) برای مثال دریافت اطلاعات رکوردی با ID مساوی یک به کمک متد Get مرتبط با شیء Session : این اطلاعات مستقیما از بانک اطلاعاتی دریافت خواهد شد.
د) سپس مجددا سعی در دریافت رکوردی با ID مساوی یک. اینبار اطلاعات این شیء مستقیما از cache خوانده میشود و رفت و برگشتی به بانک اطلاعاتی نخواهیم داشت. به همین جهت به این روش identity map هم گفته میشود، زیرا NHibernate بر اساس ID منحصربفرد این اشیاء ، identity map خود را تشکیل میدهد.
ه) خاتمهی سشن با فراخوانی متد Close آن
بلافاصله
الف) دریافت شیء Session از Session Factory
ب) شروع یک تراکنش با فراخوانی متد BeginTransaction شیء Session
ج) برای مثال دریافت اطلاعات رکوردی با ID مساوی یک به کمک متد Get مرتبط با شیء Session : این اطلاعات مستقیما از بانک اطلاعاتی دریافت خواهد شد (زیرا در یک سشن جدید قرار داریم و همچنین سشن قبلی بسته شده و کش آن تخلیه گشته است).
د) خاتمهی سشن با فراخوانی متد Close آن
سؤال: آیا استفاده از یک سشن سراسری در برنامه صحیح است؟
پاسخ: خیر!
توضیحات: زمانیکه از یک سشن سراسری استفاده میکنید، کش NHibernate را در اختیار تمام کاربران همزمان سیستم قرار دادهاید. در طی یک سشن، همانطور که عنوان شد، بر اساس IDهای اشیاء، یک identity map تشکیل میشود و در این حالت به ازای هر رکورد بانک اطلاعاتی فقط و فقط یک شیء در حافظه وجود خواهد داشت که این روش در محیطهای چندکاربره مانند برنامههای وب به زودی تبدیل به نشت اطلاعات و یا تخریب اطلاعات میگردد. به همین جهت در این نوع برنامهها روش session-per-request بهترین حالت کاری است.
سؤال: حین به روز رسانی اشیاء جدید، به خطا بر میخورم. مشکل در کجاست؟
فرض کنید شیء مفروض Customer را توسط متد session.Get از بانک اطلاعاتی دریافت و تعدادی از خواص آنرا جهت ساخت شیء جدیدی از کلاس Customer استفاده کردهایم. اکنون اگر بخواهیم این شیء جدید را در بانک اطلاعاتی ذخیره یا به روز رسانی کنیم، NHibernate این اجازه را نمیدهد! چرا؟
پاسخ:
خطای متداول این حالت عموما به صورت زیر است:
a different object with the same identifier value was already associated with the session
همانطور که عنوان شد، در طول یک سشن، نمیتوان دو شیء با یک ID را به عنوان یک رکورد بانک اطلاعاتی مورد استفاده قرار داد. اولین فراخوانی Get ، سبب کش شدن آن شیء در identity map سطح اول caching میگردد.
راه حل:
الف) از چندین و چند شیء استفاده نکنید. هر رکورد باید تنها با یک وهله از شیءایی متناظر باشد.
ب) میتوان پیش از update، کش سطح اول را به صورت دستی خالی کرد. برای این منظور از متد Clear شیء سشن استفاده کنید.
ج) بجای استفاده از متد saveOrUpdate شیء سشن، از متد Merge آن استفاده کنید. به این صورت شیء جدید ایجاد شده با شیء موجود در کش یکی خواهد شد.
د) میتوان بجای تخلیه کل کش (حالت ب)، کش مرتبط با شیء Customer را به صورت دستی خالی کرد. برای این منظور از متد Evict شیء سشن استفاده نمائید.
و لازم به ذکر است که متد Flush سبب تخلیه کش نمیگردد. کار این متد اعمال کلیه تغییرات اعمالی موجود در کش به بانک اطلاعاتی است و بیشتر جهت هماهنگ سازی این دو مورد استفاده قرار میگیرد.
سؤال: آیا میتوان سطح اول caching را غیرفعال کرد؟
پاسخ:بله.
توضیحات:
عموما کلیه ORMs جهت Batching یا Bulk data operations (برای مثال ثبت تعداد زیادی رکورد یا به روز رسانی تعداد بالایی از آنها، یا نمایش فقط خواندنی تعداد زیادی رکورد و گزارشگیری از آنها) کارآیی مطلوبی ندارند. نمونهای از آنرا در مبحث جاری ملاحظه کردهاید. هر شیءایی که به نحوی به سشن جاری وارد میشود تحت نظر قرار میگیرد و این مورد در تعداد بالای ثبت یا به روز رسانی رکوردها، یعنی کاهش سرعت و کارآیی، به علاوه مصرف بالای حافظه. به همین جهت باید به خاطر داشت که ORMs جهت سناریوهای OLTP مناسب هستند و کسانی که سرعت و کارآیی ORMs را با Batch processing اندازه گیری میکنند، کلا درکی از فلسفهی وجودی ORMs و ساختار درونی آنها ندارند!
خوشبختانه NHibernate با معرفی Stateless Sessions بر این مشکل فائق آمده است. در اینجا بجای ISession تنها کافی است از IStatelessSession استفاده گردد:
using (IStatelessSession statelessSession = sessionFactory.OpenStatelessSession())
using (ITransaction transaction = statelessSession.BeginTransaction())
{
//now insert 1,000,000 records!
}
تنها باید به خاطر داشت که در این حالت lazy loading پشتیبانی نمیشود و همچنین رخدادهای درونی NHibernate نیز لغو خواهند شد.
اشتراکها
Visual Studio 2013.1 RC منتشر شد!
به این مفهوم single sign-on میگن و توسط ASP.NET Identity پشتیبانی نمیشه. برای اینکار باید از Identity server استفاده کنید که برای یک چنین کاری از پایه طراحی شده.