درک معاملات جبرانی

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

پشتیبانی از تراکنش LDAP توسط ContextSourCetransactionManager ، یک اجرای PlatformTransactionManager ارائه می شود که پشتیبانی از معاملات بهاری را برای عملیات LDAP مدیریت می کند. همراه با همکاران خود ، عملیات LDAP را که در یک معامله انجام می شود ، پیگیری می کند و قبل از هر عمل ، سابقه دولت را ثبت می کند و در صورت نیاز به معامله ، اقدام به بازگرداندن حالت اولیه می کند.

علاوه بر مدیریت معامله واقعی ، پشتیبانی از تراکنش LDAP بهار همچنین اطمینان می دهد که از همان نمونه dircontext در طول همان معامله استفاده می شود ، یعنی DirContext تا پایان معامله در واقع بسته نخواهد شد و امکان استفاده از منابع کارآمدتر را فراهم می کند.

توجه داشته باشید

توجه به این نکته حائز اهمیت است که در حالی که رویکردی که توسط LDAP بهار برای ارائه پشتیبانی از معامله استفاده می شود برای بسیاری از موارد کافی است ، به هیچ وجه معاملات "واقعی" به معنای سنتی نیست. سرور کاملاً از معاملات بی خبر است ، بنابراین به عنوان مثالاگر اتصال شکسته شود ، امیدی به بازگرداندن معامله نخواهد بود. در حالی که باید این را با دقت در نظر گرفت ، همچنین باید توجه داشت که جایگزین کار بدون هیچ گونه پشتیبانی از معامله است. این تقریباً به همان اندازه خوب است.

توجه داشته باشید

پشتیبانی از معامله سمت مشتری علاوه بر کار مورد نیاز عملیات اصلی ، مقداری سربار نیز اضافه می کند. در حالی که این سربار نباید در بیشتر موارد نگران کننده باشد ، اگر برنامه شما چندین عمل LDAP را در همان معامله انجام ندهد (به عنوان مثال یک ModifyAttributes که به دنبال یک rebind است) ، یا اگر همگام سازی معامله با منبع داده JDBC لازم نیست (لازم نیست (در زیر مشاهده کنید) با استفاده از پشتیبانی معامله LDAP هیچ چیز برای به دست آوردن وجود نخواهد داشت.

	توجه داشته باشید
	در حالی که تنظیم پیش فرض برای بسیاری از موارد استفاده ساده خوب کار خواهد کرد ، برخی از سناریوهای پیچیده تر به پیکربندی اضافی نیاز دارند. به طور خاص اگر در معاملات ایجاد یا حذف زیر درختان را ایجاد کنید یا حذف کنید ، باید از یک TempentryRenamingStrateal جایگزین جایگزین استفاده کنید ، همانطور که در بخش 6. 4. 1 توضیح داده شده است ، "تغییر نام استراتژی ها" در زیر

6. 2. پیکربندی

پیکربندی معاملات LDAP بهار اگر عادت به پیکربندی معاملات بهاری دارید ، باید بسیار آشنا به نظر برسند. شما یک نمونه TransactionManager ایجاد خواهید کرد و هدف خود را با استفاده از TransactionProxyFactoryBean می بندید. علاوه بر این ، شما همچنین باید ContextSource خود را در یک TransactionAwareContextSourceProxy بپیچید.

در یک مثال واقعی دنیای واقعی شما احتمالاً معاملات را در سطح شیء خدمات به جای سطح DAO اعمال می کنید. موارد فوق به عنوان نمونه ای برای نشان دادن ایده کلی عمل می کند.

	توجه داشته باشید
	متوجه خواهید شد که نمونه های واقعی ContextSource و DAO با پسوند "هدف" شناسه می گیرند. لوبیا هایی که در واقع به آنها اشاره خواهید کرد ، پروکسی هستند که در اطراف اهداف ایجاد می شوند.contextSource و MyDataAccessObject

6. 3. ادغام معامله JDBC

یک مورد استفاده متداول هنگام کار در برابر LDAP این است که برخی از داده ها در درخت LDAP ذخیره می شوند ، اما داده های دیگر در یک پایگاه داده رابطه ای ذخیره می شوند. در این حالت ، پشتیبانی از معامله حتی از اهمیت بیشتری برخوردار می شود ، زیرا به روزرسانی منابع مختلف باید هماهنگ شود.

در حالی که معاملات واقعی XA پشتیبانی نمی شود ، پشتیبانی از دسترسی مفهومی دسترسی JDBC و LDAP در همان معامله با استفاده از ContextSourceAndDatasourCetransactionAnager ارائه می شود. یک منبع داده و یک ContextSource به ContextSourCeandDatasourCetransactionManager عرضه می شود ، که سپس این دو معاملات را مدیریت می کند ، به طور واقعی انگار که آنها یکی هستند. هنگام انجام یک تعهد ، قسمت LDAP این عملیات همیشه ابتدا انجام می شود و اجازه می دهد در صورت عدم موفقیت LDAP ، هر دو معاملات به عقب برگردند. بخش JDBC از معامله دقیقاً مانند DataSourcetransactionManager مدیریت می شود ، به جز اینکه معاملات تو در تو پشتیبانی نمی شود.

	توجه داشته باشید
	یک بار دیگر لازم به ذکر است که پشتیبانی ارائه شده همه طرف مشتری است. معامله بسته بندی شده معامله XA نیست. هیچ دو فاز به عنوان این تعهد انجام نمی شود ، زیرا سرور LDAP قادر به رأی دادن به نتیجه خود نخواهد بود. با این حال ، بار دیگر ، برای اکثر موارد ، پشتیبانی تأمین شده کافی خواهد بود.

6. 4. معاملات جبران کننده LDAP توضیح داده شده است

Spring LDAP با ایجاد سابقه کار در درخت LDAP قبل از هر عملیات اصلاح ، معاملات جبران خسارت را مدیریت می کند (Bind ، Unbind ، Rebind ، ModifyAttributes و تغییر نام).

این سیستم را قادر می سازد تا در صورت نیاز به معامله ، عملیات جبران کننده را انجام دهد. در بسیاری از موارد ، عملکرد جبران کننده بسیار ساده است. به عنوان مثال. عملکرد جبران خسارت برای یک عملیات اتصال کاملاً بدیهی است که ورودی را خنثی می کند. اما سایر عملیات به دلیل برخی از ویژگی های خاص پایگاه داده های LDAP به یک رویکرد متفاوت و پیچیده تر نیاز دارند. به طور خاص ، همیشه نمی توان مقادیر تمام ویژگی های یک ورودی را بدست آورد ، و استراتژی فوق را برای مثال کافی نداریم. یک عملیات بی بند و باری.

به همین دلیل است که هر عملیات اصلاح شده در یک معامله مدیریت شده LDAP بهار در چهار عملیات مجزا تقسیم می شود - یک عملیات ضبط ، یک عملیات آماده سازی ، یک عملیات تعهد و یک عملیات برگشت. مشخصات مربوط به هر عمل LDAP در جدول زیر شرح داده شده است:

شرح مفصلی در مورد عملکرد داخلی پشتیبانی از معامله LDAP بهار در Javadocs در دسترس است.

6. 4. 1. استراتژی های تغییر نام

همانطور که در جدول بالا توضیح داده شده است ، مدیریت معامله برخی از عملیات نیاز به ورود اصلی تحت تأثیر این عملیات دارد تا قبل از اصلاح واقعی در تعهد ، به طور موقت تغییر نام یابد. نحوه محاسبه DN موقت ورود توسط یک TempentryRenamingStrategy که به ContextSourcetransactionager ارائه می شود ، مدیریت می شود. دو پیاده سازی با LDAP بهار ارائه می شود ، اما در صورت نیاز به رفتار خاص ، اجرای سفارشی به راحتی توسط کاربر قابل اجرا است. پیاده سازی های ارائه شده TempentryRenamingStrategy عبارتند از:

DefaultTempentryRenamingStrategy (پیش فرض). پسوند را به کمترین قسمت قابل توجه DN اضافه می کند. به عنوان مثال. برای DN CN = John Doe ، OU = کاربران ، این استراتژی DN CN = John Doe_Temp ، OU = کاربران را برمی گرداند. پسوند با استفاده از ویژگی Tempsuffix قابل تنظیم است

تفاوتهای مختلف PentryRenamingStrategy. کمترین بخش از DN را به خود اختصاص می دهد و یک DN Subtree را به این امر اضافه می کند. این باعث می شود همه ورودی های موقت در یک مکان خاص در درخت LDAP قرار بگیرند. Subtree DN موقت با استفاده از ویژگی Subtreenode پیکربندی شده است. به عنوان مثال ، اگر subtreenode ou = tempentries باشد و DN اصلی ورودی CN = John doe ، OU = کاربران است ، DN موقت CN = John Doe ، ou = tempentries خواهد بود. توجه داشته باشید که گره Subtree پیکربندی شده باید در درخت LDAP وجود داشته باشد.