الخلفية: لنفس السجل في قاعدة البيانات ، إذا قام شخصان بتعديل البيانات في نفس الوقت ، ثم يزامنها أخيرًا مع قاعدة البيانات ، فلن تكون النتيجة غير متوقعة بسبب التزامن. الحل الأسهل هو إضافة حقل إصدار إلى السجل في الجدول. عند تعديل السجل ، تحتاج إلى مقارنة ما إذا كان الإصدار يتطابق. إذا كان يتطابق ، فسيتم تحديثه ، وإذا لم يتطابق ، فسوف يفشل مباشرة. إذا نجح التحديث ، يتم تعيين الإصدار+1 ، وهو ما يسمى القفل المتفائل. بالطبع ، من الأفضل أن يكون هذا المنطق شفافًا للمطورين ، وهذا المكون الإضافي هنا للقيام بذلك.
1. طريقة الاستخدام: أضف التكوين التالي إلى ملف تكوين MyBatis ويتم اكتماله.
<uccedins> <plugin interceptor = "com.chrhc.mybatis.locker.Interceptor.optimisticlocker"/> </sugionins>
2. وصف تكوين المكونات:
سمة Java المقابلة لعمود القفل المتفائل لتكوين قاعدة البيانات الافتراضي للإصدار هو الإصدار. هنا يمكنك تخصيص حياة السمة ، على سبيل المثال:
<uccedins> <plugin interceptor = "com.chrhc.mybatis.locker.Interceptor.OpTimisticLocker"> <property name = "versionColumn" value = "XXX"/> <!
3. التأثير:
سابقا: تحديث اسم تعيين المستخدم =؟ ، كلمة المرور =؟ أين المعرف =؟
بعد: تحديث اسم تعيين المستخدم =؟ ، كلمة المرور =؟ ، الإصدار = الإصدار+1 أين المعرف =؟ والنسخة =؟
4. وصف قيمة الإصدار:
1. عند الحصول على قيمة الإصدار ، سيزداد المكون الإضافي تلقائيًا بمقدار 1.
2. إن عملية التحكم بأكملها للقفل المتفائل شفافة للمستخدم ، والتي تشبه إلى حد كبير قفل Hibernate المتفائل ، ولا يحتاج المستخدمون إلى الاهتمام بقيمة القفل المتفائل.
5. وصف مبدأ الإضافات:
يعترض المكون الإضافي عبارة التحديث التي تم تنفيذها بواسطة MyBatis ويضيف علامة قفل متفائلة على عبارة SQL الأصلية. على سبيل المثال ، SQL الأصلي هو:
تحديث اسم تعيين المستخدم =؟ ، كلمة المرور =؟ أين المعرف =؟ ،
ثم لا يحتاج المستخدم إلى تعديل عبارة SQL. بمساعدة المكون الإضافي ، سيتم إعادة كتابة عبارة SQL أعلاه تلقائيًا على النحو التالي:
تحديث اسم تعيين المستخدم =؟ ، كلمة المرور =؟ ، الإصدار = الإصدار + 1 أين المعرف =؟ والنسخة =؟ ،
النموذج ، لا يتعين على المستخدمين الاهتمام بالقيمة قبل الإصدار وبعده. جميع الإجراءات شفافة للمستخدمين ، ويكمل المكون الإضافي هذه الوظائف بأنفسهم.
6. الاتفاقية الافتراضية:
1. عبارات عبارة التحديث التي تم اعتراضها بواسطة هذا المكون الإضافي كلها مُعدّة ، وهو أمر صالح فقط لـ SQL بهذه الطريقة ؛
2. يجب أن تتوافق علامة <uptuday> من mapper.xml مع طريقة Mapper الواجهة ، أي باستخدام الطريقة الموصى بها من قبل MyBatis ، ولكن يمكن أن تتوافق واجهات متعددة مع علامة mapper.xml <uptuday> ؛
3. هذا المكون الإضافي لن يفعل أي شيء لنتائج SQL ، وما يجب أن يعود SQL نفسه هو ما ؛
4. يعترض المكون الإضافي على جميع عبارات التحديث بشكل افتراضي. إذا كان المستخدم لا يريد التحكم في القفل المتفائل لتحديث معين ، فقم بإضافة exproventlocker (false) أو versionlocker (value = false) إلى طريقة واجهة Mapper المقابلة ، بحيث لن يفعل المكون الإضافي أي شيء لهذا التحديث ، وهو ما يعادل عدم وجود هذا المكون الإضافي ؛
5. هذا المكون الإضافي حاليًا لا يدعم الأقفال المتفائلة لتحديثات الدُفعات في الوقت الحالي. والسبب هو أن تحديثات الدُفعات لا تحتوي على العديد من سيناريوهات التطبيق في التطوير الفعلي ، ومن الصعب تطوير أقفال متفائلة لتحديثات الدُفعات ؛
6. يجب أن يكون نوع المعلمة لواجهة Mapper متسقة مع النوع الفعلي الذي تم تمريره. وذلك لأنه في إصدار JDK ، لا توجد طريقة أدناه JDK8 للحصول على اسم قائمة المعلمة للواجهة. لذلك ، يستخدم المكون الإضافي أنواع المعلمات والمعلمات كتعيينات لمطابقة توقيع الطريقة ؛
عنوان github: https://github.com/xjs1919/locker
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.