لماذا يستهلك Eclipselink التخصيص الكامل في كل مرة يتم إعادة تشغيلها؟

Question

لقد لاحظت للتو أنه بالنسبة لمعرف الكيان الخاص بي ، يقوم Eclipselink بتعيين معرف 1 + الذي تم تعيينه مسبقًا في نفس الجلسة (1) ، كما في جدول العناصر (2). هذا يتعارض مع توقعاتي.

ما هي أسهل طريقة لإخبارها أن تفعل 2؟

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private int objId;

وهنا ما لدي في قاعدة البيانات:

ij> connect 'jdbc:derby:db';
ij> set schema memo;
0 Zeilen eingef?gt/aktualisiert/gel?scht
ij> select * from meaning;
OBJID      |LASTPUBLI&|USR_EMAIL                                                                                                                       
-------------------------------------------------------------------------------------------------------------------------------------------------------
1          |NULL      |NULL                                                                                                                            
2          |2010-10-27|NULL                                                                                                                            
51         |NULL      |NULL                                                                                                                            
101        |NULL      |NULL                                                                                      

Answer 1

عند استخدام GenerationType.AUTO الاستراتيجية مع Derby ، الافتراضات Eclipselink إلى أ مولد الجدول إستراتيجية.

ثم ، عند إنشاء Id مطلوب ، سوف EL Preallocate IDS وفقا ل allocationSize (وهو 50 بشكل افتراضي). للقيام بذلك ، سيقوم أولاً بتحديث العمود الذي يخزن القيمة الأخيرة التي تم إنشاؤها لزيادةها بواسطة allocationSize:

UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT + ? WHERE SEQ_NAME = ?
    bind => [50, SEQ_GEN]

ثم سوف تقرأ القيمة الجديدة:

SELECT SEQ_COUNT FROM SEQUENCE WHERE SEQ_NAME = ?
    bind => [SEQ_GEN]

بمجرد الانتهاء من ذلك ، preallocates مجموعة من المعرفات باستخدام التيار القيمة - تخصيص + 1 كـ "الأول" و القيمة كـ "الماضي":

local sequencing preallocation for SEQ_GEN: objects: 50 , first: 1, last: 50

وسوف يقدم معرفات من الذاكرة حتى تصل إلى القيمة الأخيرة وستعيد تشغيل دورة.

الآن ، إذا قمت بإعادة تشغيل JVM ، فلا توجد طريقة آمنة أخرى لـ EL غير تمييز مجموعة جديدة من المعرفات ، "فقدان" تلك من النطاق "السابق" الذي لم يتم استخدامه (فكر في Multi-JVMs وما إلى ذلك) ، وهو ما يشرح "القفز" من 2 إلى 51 في مثالك.

إذا كنت تريد تجنب ذلك ، فإن اقتراحي هو التبديل إلى IDENTITY الإستراتيجية التي يدعمها ديربي (لا أعتقد أن تكوين مولد الجدول لاستخدام allocationSize من 1 ستكون فكرة جيدة).

---

لا أعتقد أن تكوين مولد الجدول لاستخدام تخصيص 1 سيكون فكرة جيدة. لما لا؟

بسبب أداء الأداء إذا كان عليك القراءة من جدول "التسلسل" لكل إدراج. ولكن من ناحية أخرى ، 1) قد لا يكون هذا مصدر قلق في حالتك 2) هذه هي الإستراتيجية الوحيدة التي تسمح بالحصول على معرفات متسلسلة حقًا.

إذا كنت مهتمًا ، فيجب أن تكون قادرًا على تكوين هذا العالم باستخدام ملف table-generator عنصر في واصف XML.

لا تشجع El إلى حد كبير استراتيجية الهوية ، إلى جانب ذلك ، يبدو أن هناك مناجمًا (لأنه يجب عليك الانتظار للالتزام قبل قراءة القيمة ، وهو شيء قد أفعله في مكان ما).

حسنًا ، لا يمكنني التأكيد على EL (لن أختبر هذا الآن) لكن السبات يؤدي إدراجًا فوريًا على persist عندما تستخدم IDENTITY إستراتيجية. اعتقدت أن إل سيتصرف بنفس الطريقة. لكنني قد أكون مخطئًا ، هذا لا يبدو مفوضًا بالمواصفات.

مراجع

• JPA Wikibook
  • استراتيجيات التسلسل
  • استراتيجيات تسلسل التسلسل المتقدمة