چرا CMT وقتی ویژگی معامله "مورد نیاز" است ، در خروج از روش EJB متعهد می شود؟

من به طور مداوم می فهمم که معامله از قبل موجود من در هر روش EJB مشخص شده @ejb. transaction نوع = "مورد نیاز" انجام می شود. آیا این می تواند صحیح باشد؟انتظار من این است ، یک EJB "که به" معامله "نیاز دارد: اگر یکی از آنها در آنجا وجود داشته باشد ، در صورت اتمام کار مودبانه ، آن را غیرقانونی رها می کند تا هرکسی که دعوت شده است شروع شود () می تواند قبل از استناد به تعهد () یا بازگشت () از آن برای عملیات بیشتر استفاده کند ()).[البته ، اگر در وهله اول معامله ای وجود نداشته باشد ، روش EJB هم شروع می شود () و هم متعهد () / بازگرداندن ().] آیا انتظار من اشتباه است ، یا باید به دنبال یک اشکال پیکربندی باشم؟ممکن است این نکته مهم باشد که اضافه کنم که من از Hibeate 3 در داخل EJB استفاده می کنم. من قبل از تماس با روش EJB ، یک کاربر را به دست می آورم. بسته بندی EJB تولید شده ServerTransaction. commit () را در خروجی فراخوانی می کند ، که خواب زمستانی به آن قلاب می کند و از فرصتی برای بستن جلسه خود استفاده می کند. خطایی که من دریافت می کنم یک استثناء بارگذاری تنبل است ، زیرا جلسه بسته می شود وقتی که سعی می کنم به یک شیء باکره دسترسی پیدا کنم. بنابراین از نظر فنی ، من 100 ٪ مطمئن نیستم که آیا ServerTransaction. commit () من را لزوماً مرتکب استفاده از userTransaction شدم (شاید ServerTransaction. commit () همیشه با یک "تعهد" واقعی "دنبال نمی شود ، اما اگر اگراین کار را نکرد - پس از آن که Hibeate جلسه را می بندد چه مبنایی دارد؟بروزرسانی: من معتقدم فرضیات من در بالا صحیح بود ، اما مشاهدات من کمی خاموش بود. برای پاسخ خودپرداز من در زیر مشاهده کنید.

دنبال کردن 26. 9k 103 103 نشان های طلا 329 329 نشان نقره 596 596 نشان های برنز از 25 آگوست 2011 در ساعت 19:42 پرسید نكاركلك 1،012 1 1 نشان طلا 11 11 نشان نقره 16 16 نشان برنز

"اگر یکی از آنها در آنجا وجود داشته باشد ، آن را مودبانه رها می کند." آیا از درک خود در اینجا مطمئن هستید؟از پاسخ پذیرفته شده شما ، "userTransaction که من شروع کردم باز مانده است ، اما CMT علی رغم ویژگی" مورد نیاز "، معامله جدیدی را برای ورود به روش EJB ایجاد کرد. این یک تلاش برای ایجاد معامله تو در تو است و در عوض باید یک استثنا ایجاد کندمانند - javax. transaction. notsupportedexception: معامله تو در تو پشتیبانی نمی شود.، از آنجا که معاملات تو در تو در جاوا EE پشتیبانی نمی شود. من کاملاً در مورد آنچه قبلاً درباره CMT و BMT می دانستم گمراه شدم.

29 آگوست 2015 در 5:59 آیا می توانید سناریوی آزمون را که از چهار سال پیش استفاده شده است به خاطر بسپارید؟ 29 آگوست 2015 ساعت 6:00

Tiny - من به یاد دارم که هر دو به روش های مختلفی که کاربری من باز مانده است ، تأیید می کنم و معامله CMT برای خروج از EJB با مدیریت کانتینر انجام شده است. این درک به من این امکان را داد که اگر با لطف و نه ، اوضاع را با موفقیت در خود جای دهم. من هرگز چیزی پیدا نکردم که نشان دهم WL ثابت شده است که رفتار دیگری انجام داده است (توجه داشته باشید که آزمایشات ذکر شده توسط Davidblevens طبق گفته های وی از اجباری استفاده شده است ، همانطور که مورد من لازم نبود). این 3-4 قرارداد قبل بود ، بنابراین من نمی توانم بیش از این به شما بدهم ، متاسفم.

30 آگوست 2015 در 15:39

من از اشتباه Davidblevins عذرخواهی می کنم. ظاهراً دیگر نمی توانم آن را برطرف کنم زیرا 5 دقیقه از بین رفته است.

30 آگوست 2015 ساعت 15:48

4 پاسخ 4

مرتب شده توسط: تنظیم مجدد به طور پیش فرض

مورد نیاز می تواند شر باشد

من شخصاً ویژگی معامله مورد نیاز را دوست ندارم و به شدت از استفاده از آن دلسرد می شوم.

ایجاد تنبل ایجاد معاملات (که این همان چیزی است که لازم است) منجر به این امر نمی شود که واقعاً نمی داند چه زمانی و از کجا معامله آغاز شده است و چه زمانی مرتکب خواهد شد. این چیز خوبی نیست. مردم باید صریحاً مرزهای معامله ای را طراحی کنند.

اجباری و کاربری تراشون همدستان روح هستند

تمایل شما به استفاده از یک کاربری کاربری بسیار خوب است و با CMT کار می کند - هیچ تفاوتی بین معامله JTA که از طریق UserTransaction تهیه شده توسط کانتینر یا معامله JTA برای شما آغاز شده است ، هیچ تفاوتی وجود ندارد.

رویکردی که من توصیه می کنم این است که تمام استفاده های مورد نیاز را به اجباری تغییر دهید. با اجباری کانتینر معاملات را برای شما شروع نمی کند. در عوض ، با اطمینان از عدم تماس با آن ، از لوبیا شما محافظت می کند ، مگر اینکه معامله در حال انجام باشد. این یک ویژگی شگفت انگیز و کم استفاده است. اجباری بهترین دوست هرکسی است که می خواهد یک برنامه معامله ای واقعاً قطعی ایجاد کند و آن را اجرا کند. با این تنظیم ممکن است عاشق CMT باشید.

در این سناریو معاملات را با UserTransactions شروع می کنید و سپس ظرف مانند محافظ بزرگ شما است که افراد را به سمت مهار لگد می زند ، مگر اینکه آنها قبل از تلاش برای استناد به کد شما ، معامله مناسب را شروع کرده اند.

ملاحظات

• یک سرویس یا BMT EJB می تواند از یک کاربری استفاده کند.
• لوبیای CMT نمی تواند از یک کاربری استفاده کند ، اما آنها می توانند در معامله ای که توسط یک کاربر انجام شده است شرکت کنند (همانطور که در بالا ذکر شد ، معامله JTA یک معامله JTA است).
• دانه های BMT نمی توانند در یک تراکنش موجود شرکت کنند. اگر زمانی که تراکنش در حال انجام است، یک Bean را فراخوانی کنید، تراکنش قبل از فراخوانی BMT bean توسط کانتینر به حالت تعلیق در می آید و پس از تکمیل روش از سر گرفته می شود.
• @Resource UserTransaction تراکنش کاربر را از طریق تزریق دریافت می کند
• java:comp/UserTransaction تراکنش کاربر را از طریق جستجو دریافت می کند
• @TransactionAttribute(اجباری) که در سطح کلاس استفاده می شود، بر روش های آن کلاس تأثیر می گذارد (یعنی متدهای fooClass. getDecaredMethods()). متدهای سوپر کلاس ها و زیر کلاس ها به طور پیش فرض روی TransactionAttribute@(الزامی) خواهند بود، مگر اینکه آن کلاس ها نیز به صراحت حاشیه نویسی شده باشند @TransactionAttribute (اجباری)
• اگر از تماس ()userTransaction. begin و userTransaction. commit() و انجام رسیدگی به استثناهای مربوطه خسته شدید، @TransactionAttribute(REQUIRES_NEW) را در نظر بگیرید. مرزهای تراکنش شما همچنان مستند و صریح خواهد بود.
• RuntimeException پرتاب شده از روشی از یک لوبیا CMT باعث می شود که تراکنش برای بازگشت علامت گذاری شود، حتی اگر استثنا را در کد فراخوانی بگیرید و مدیریت کنید. از ApplicationException@ برای غیرفعال کردن این مورد به مورد برای کلاس های استثنای زمان اجرا سفارشی استفاده کنید.

از دست دادن زمینه تراکنش

چند چیز می تواند باعث شود که تراکنش در حال انجام شما متوقف شود، به حالت تعلیق درآید یا به صورت دیگری به Bean فراخوانی نشود.

• دانه های BMT انتشار معاملات را متوقف می کند. اگر یک تراکنش در حال انجام، یک BMT bean را فراخوانی کند، آن تراکنش قبل از فراخوانی BMT bean به حالت تعلیق در می آید و پس از بازگشت bean از سر گرفته می شود. دانه های BMT می توانند مبدا معاملات باشند اما نمی توانند در تراکنش های موجود شرکت کنند. اگر انتشار به طور مرموزی با شکست مواجه شد، مطمئن شوید که در اواسط تراکنش تماس های غیرعمدی با دانه های BMT وجود ندارد.
• برای مدیریت تراکنش ها از هیچ چیز دیگری به جز UserTransaction ارائه شده توسط کانتینر یا روش های ارائه شده در کانتینر مانند SessionContext. setRollbackOnly استفاده نکنید. استفاده از "API تعیین تراکنش خاص مدیر منبع" مانند JPA EntityTransaction یا java. sql. Connection. commit() مدیریت تراکنش را دور می زند.
• تاپیک های خودتون رو شروع نکنیدانتشار تراکنش بر اساس هر رشته انجام می شود. هیچ API استانداردی در جاوا EE وجود ندارد که از تراکنش های چند رشته ای پشتیبانی کند. اگر موضوع را از راه اندازی رشته خود یا با استفاده از @Asynchronous ترک کنید، تراکنش موجود خود را پشت سر می گذارید.