উত্তর:
উত্তম প্রশ্ন, যদিও উত্তর দেওয়ার মতো তুচ্ছ নয়।
কীভাবে লেনদেন একে অপরের সাথে সম্পর্কিত তা সংজ্ঞায়িত করে। সাধারণ বিকল্পগুলি:
Required: কোড সর্বদা লেনদেনে চলবে। একটি নতুন লেনদেন তৈরি করে বা উপলভ্য হলে পুনরায় ব্যবহার করে।Requires_new: কোড সর্বদা একটি নতুন লেনদেনে চলবে। যদি বিদ্যমান থাকে তবে বর্তমান লেনদেন স্থগিত করে।লেনদেনের মধ্যে ডেটা চুক্তি সংজ্ঞায়িত করে।
Read Uncommitted: নোংরা পড়ার অনুমতি দেয়।Read Committed: নোংরা পড়তে দেয় না।Repeatable Read: একই লেনদেনে যদি একটি সারি দু'বার পাঠ করা হয় তবে ফলাফল সর্বদা একই হবে।Serializable: একটি ক্রমানুসারে সমস্ত লেনদেন সম্পাদন করে।একাধিক-থ্রেড অ্যাপ্লিকেশনটিতে বিভিন্ন স্তরের বিভিন্ন কর্মক্ষমতা বৈশিষ্ট্য রয়েছে। আমি মনে করি আপনি dirty readsধারণাটি বুঝতে পারলে আপনি একটি ভাল বিকল্প নির্বাচন করতে সক্ষম হবেন।
যখন কোনও নোংরা পাঠ ঘটতে পারে তার উদাহরণ:
thread 1 thread 2
| |
write(x) |
| |
| read(x)
| |
rollback |
v v
value (x) is now dirty (incorrect)সুতরাং একটি বুদ্ধিমান ডিফল্ট (যদি এটি দাবি করা যায়) হতে পারে Read Committed, যা কেবলমাত্র সেই মানগুলি পড়তে দেয় যা ইতিমধ্যে অন্যান্য চলমান লেনদেন দ্বারা প্রতিশ্রুতিবদ্ধ হয়েছে, এর প্রচারের স্তরের সাথে একত্রিত হয়ে Required। তারপরে যদি আপনার অ্যাপ্লিকেশনটির অন্য প্রয়োজনীয়তা থাকে তবে আপনি সেখান থেকে কাজ করতে পারেন।
provideServiceরুটিনে প্রবেশের সময় সর্বদা একটি নতুন লেনদেন যেখানে তৈরি হবে এবং চলে যাওয়ার সময় সম্পূর্ণ হবে তার একটি বাস্তব উদাহরণ :
public class FooService {
private Repository repo1;
private Repository repo2;
@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
repo1.retrieveFoo();
repo2.retrieveFoo();
}
}আমরা পরিবর্তে ব্যবহার করেছিল Requiredলেনদেন খোলা থাকবে যদি লেনদেনের যখন রুটিন লিখে ইতিমধ্যেই খোলা ছিল। আরও নোট করুন যে rollbackবেশিরভাগ ফাঁসি একই লেনদেনে অংশ নিতে পারে বলে একটির ফলাফল আলাদা হতে পারে।
আমরা সহজেই একটি পরীক্ষার সাথে আচরণটি যাচাই করতে পারি এবং দেখতে পারি কীভাবে প্রচারের মাত্রার সাথে আলাদা হয়:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:/fooService.xml")
public class FooServiceTests {
private @Autowired TransactionManager transactionManager;
private @Autowired FooService fooService;
@Test
public void testProvideService() {
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
fooService.provideService();
transactionManager.rollback(status);
// assert repository values are unchanged ...
}এর প্রচারের স্তর সহ
Requires new: আমরা আশা fooService.provideService()ছিল না ফিরে ঘূর্ণিত যেহেতু এটি তৈরি হওয়া নিজের উপ-লেনদেন আছে।
Required: আমরা প্রত্যাশা করব যে সবকিছু আবার ঘুরিয়ে দেওয়া হয়েছে এবং ব্যাকিং স্টোরটি অপরিবর্তিত ছিল।
sessionFactory.getCurrentTransaction()হয়েছিল HibernateTemplateলেনদেন পরিচালনার জন্য আর চালানোর দরকার নেই। আমি এটি সরিয়ে দিয়েছি :)
PROPAGATION_REQUIRED = 0 ; যদি ডেটাসোর্স ট্রান্সজেকশনজেক্ট টি 1 যদি ইতিমধ্যে মেথড এম 1 এর জন্য শুরু হয়ে থাকে তবে অন্য কোনও পদ্ধতি এম 2 এর জন্য যদি লেনদেনের প্রয়োজন হয় তবে কোনও নতুন ট্রানজেকশন অবজেক্ট তৈরি করা হয় না। এম 2 এর জন্য একই বস্তু টি 1 ব্যবহার করা হয়
PROPAGATION_MANDATORY = 2 ; পদ্ধতি অবশ্যই একটি লেনদেনের মধ্যে চলতে হবে। যদি কোনও বিদ্যমান লেনদেন চলমান থাকে তবে একটি ব্যতিক্রম ছুঁড়ে দেওয়া হবে
PROPAGATION_REQUIRES_NEW = 3 ; যদি পদ্ধতি এম 1 এর জন্য ডেটাসোর্স ট্রানজেকশনঅবজেক্ট টি 1 ইতিমধ্যে শুরু হয়েছে এবং এটি প্রক্রিয়া এম 1 কার্যকর করছে (অন্য পদ্ধতিতে এম 2 কার্যকর করা শুরু করে) তবে M2 এর জন্য নতুন ডেটাসোর্স ট্রান্সঅশনঅজেক্ট টি 2 দিয়ে পদ্ধতি এম 2 এর সময়কালের জন্য টি 1 স্থগিত করা হয়েছে। এম 2 তার নিজের লেনদেন প্রসঙ্গে চলে
PROPAGATION_NOT_SUPPORTED = 4 ; যদি পদ্ধতি এম 1 এর জন্য ডেটাসোর্স ট্রান্সজেকশনজেক্ট টি 1 ইতিমধ্যে শুরু করা হয়েছে another তবে অন্য কোনও পদ্ধতি যদি এম 2 একযোগে চালিত হয় hen তবে এম 2 লেনদেন প্রসঙ্গে চলবে না। এম 2 শেষ না হওয়া পর্যন্ত টি 1 স্থগিত করা হয়েছে।
PROPAGATION_NEVER = 5 ; কোনওটিই লেনদেন প্রসঙ্গে চালিত হয় না।
একটি বিচ্ছিন্নতা স্তর: এটি অন্যান্য সমবর্তী লেনদেনগুলির ক্রিয়াকলাপ দ্বারা কোনও লেনদেনের উপর কতটা প্রভাব ফেলতে পারে is এটি একটি ধারাবাহিকতাটিকে অনেক টেবিলের মধ্যে তথ্যকে একটি সুসংগত অবস্থায় রেখে দেয় supports এটিতে একটি ডাটাবেসে সারি এবং / অথবা সারণীগুলি লক করা জড়িত।
একাধিক লেনদেন নিয়ে সমস্যা
দৃশ্যপট 1 .যদি টি 1 লেনদেনটি সারণি A1 থেকে ডেটা পড়েন যা অন্য একত্রে লেনদেন টি 2 দ্বারা লেখা হয়েছিল T টি T2 রোলব্যাক হয় সে পথে টি 1 দ্বারা প্রাপ্ত ডেটাটি অবৈধ g 1 টি টি 2 দ্বারা রচিত হয়েছিল। টি টি যদি রোলব্যাক করে তবে একটি = 1 টি ডিবিতে একটি = 2 এ রোলব্যাক হবে তবে এখন, টি 1 এর একটি = 1 আছে তবে ডিবি টেবিলটিতে এটি = 2 এ পরিবর্তিত হবে।
পরিস্থিতি 2 .যদি টি 1 লেনদেন সারণি A1 থেকে ডেটা পড়েন table যদি অন্য একসাথে লেনদেন (টি 2) টেবিল এ 1 তে ডেটা আপডেট করে T তবে টি 1 পড়েছে এমন তথ্যটি টেবিল এ 1 থেকে আলাদা ec কারণ টি 2 টেবিল এ 1 তে ডেটা আপডেট করেছে T পড়ুন a = 1 এবং টি 2 আপডেট হয়েছে a = 2. তারপরে! = খ।
পরিস্থিতি ৩ । যদি অন্য সমবর্তী লেনদেন (টি 2) সারণি A1 এ আরও সারি সন্নিবেশ করায় T টি 1 পঠিত সারিগুলির সংখ্যা টেবিল A1 এর সারিগুলির চেয়ে পৃথক is
পরিস্থিতি 1 বলা হয় ডার্টি রিড বলা হয়।
পরিস্থিতি 2 বলা হয় অ-পুনরাবৃত্তযোগ্য পাঠ বলা হয়।
পরিস্থিতি 3 বলা হয় ফ্যানটম রিডস।
সুতরাং, বিচ্ছিন্নতা স্তর যা প্রসারিত হয় 1, পরিস্থিতি 2, পরিস্থিতি 3 প্রতিরোধ করা যায়। আপনি লকিং প্রয়োগ করে সম্পূর্ণ বিচ্ছিন্নতা স্তর অর্জন করতে পারেন hat এটি একই তথ্য ঘটতে থাকা থেকে সমবর্তী পড়তে বা লিখতে বাধা দিচ্ছে B তবে এটি কার্য সম্পাদনকে প্রভাবিত করে। বিচ্ছিন্নতার মাত্রা প্রয়োগের উপর নির্ভর করে কত বিচ্ছিন্নতা প্রয়োজন।
ISOLATION_READ_UNCOMMITTED : এমন পরিবর্তনগুলি পড়ার অনুমতি দেয় যা এখনও প্রতিশ্রুতিবদ্ধ হয় নি I এটি পরিস্থিতি 1, পরিস্থিতি 2, পরিস্থিতি 3 এ ভুগছে
ISOLATION_READ_COMMITTED : সমকালীন লেনদেনগুলি পড়ার অনুমতি দেয় যা প্রতিশ্রুতিবদ্ধ হয়েছিল। এটি পরিস্থিতি 2 এবং পরিস্থিতি 3 এ ভুগতে পারে কারণ অন্যান্য লেনদেনগুলি ডেটা আপডেট করে।
ISOLATION_REPEATABLE_READ : একাধিক একই মাঠের সার্চ একই ফলাফল উত্পাদ হবে untill এটা itself.It দ্বারা পরিবর্তিত হয় ডেটা ঢোকাতে করা যেতে পারে দৃশ্যপট 3.Because অন্যান্য লেনদেন থেকে ভুগতে হতে পারে
ISOLATION_SERIALIZABLE : দৃশ্যপট 1, দৃশ্যপট 2, দৃশ্যপট 3 কখনোই happens.It সম্পূর্ণ isolation.It পূর্ণ locking.It affets কারণ লকিং কর্মক্ষমতা জড়িত হয়।
আপনি ব্যবহার করে পরীক্ষা করতে পারেন
public class TransactionBehaviour {
// set is either using xml Or annotation
DataSourceTransactionManager manager=new DataSourceTransactionManager();
SimpleTransactionStatus status=new SimpleTransactionStatus();
;
public void beginTransaction()
{
DefaultTransactionDefinition Def = new DefaultTransactionDefinition();
// overwrite default PROPAGATION_REQUIRED and ISOLATION_DEFAULT
// set is either using xml Or annotation
manager.setPropagationBehavior(XX);
manager.setIsolationLevelName(XX);
status = manager.getTransaction(Def);
}
public void commitTransaction()
{
if(status.isCompleted()){
manager.commit(status);
}
}
public void rollbackTransaction()
{
if(!status.isCompleted()){
manager.rollback(status);
}
}
Main method{
beginTransaction()
M1();
If error(){
rollbackTransaction()
}
commitTransaction();
}
}বিচ্ছিন্নতা এবং বংশবিস্তার জন্য বিভিন্ন মান সহ আপনি ফলাফলটি ডিবাগ করতে এবং দেখতে পারেন।
প্রতিটি প্যারামিটার সম্পর্কে পর্যাপ্ত ব্যাখ্যা অন্যান্য উত্তর দিয়ে দেওয়া হয়; তবে আপনি একটি বাস্তব বিশ্বের উদাহরণ চেয়েছিলেন, এখানে একটি এটি বিভিন্ন প্রচারের উদ্দেশ্য স্পষ্ট করে বিকল্পের :
মনে করুন আপনি কোনও সাইনআপ পরিষেবাটি প্রয়োগের দায়িত্বে আছেন যাতে ব্যবহারকারীর কাছে একটি নিশ্চিতকরণ ইমেল প্রেরণ করা হয়। আপনি দুটি পরিষেবা অবজেক্ট নিয়ে এসেছেন, একটি ব্যবহারকারীর তালিকাভুক্তির জন্য এবং একটি ইমেল প্রেরণের জন্য , যা প্রথমটিকে প্রথমটির অভ্যন্তরে বলা হয়। উদাহরণস্বরূপ:/* Sign Up service */
@Service
@Transactional(Propagation=REQUIRED)
class SignUpService{
...
void SignUp(User user){
...
emailService.sendMail(User);
}
}
/* E-Mail Service */
@Service
@Transactional(Propagation=REQUIRES_NEW)
class EmailService{
...
void sendMail(User user){
try{
... // Trying to send the e-mail
}catch( Exception)
}
}আপনি লক্ষ্য করেছেন যে দ্বিতীয় পরিষেবাটি REQUIRES_NEW প্রসারণ প্রকারের এবং তারপরে সম্ভাবনা রয়েছে এটির ব্যতিক্রম (এসএমটিপি সার্ভার ডাউন, অবৈধ ই-মেল বা অন্যান্য কারণ)। আপনি সম্ভবত পুরো প্রক্রিয়াটি রোল-ব্যাক করতে চান না, যেমন ডাটাবেস বা অন্যান্য জিনিস থেকে ব্যবহারকারীর তথ্য অপসারণ; অতএব আপনি পৃথক লেনদেনে দ্বিতীয় পরিষেবাটিকে কল করবেন।
আমাদের উদাহরণে ফিরে আসুন, এবার আপনি ডাটাবেস সুরক্ষার বিষয়ে উদ্বিগ্ন, সুতরাং আপনি আপনার ডিএও ক্লাসগুলি এইভাবে সংজ্ঞায়িত করুন:/* User DAO */
@Transactional(Propagation=MANDATORY)
class UserDAO{
// some CRUD methods
}এর অর্থ হ'ল যখনই কোনও ডিএও অবজেক্ট, এবং সেইজন্য ডিবিতে একটি সম্ভাব্য অ্যাক্সেস তৈরি হয়, তখন আমাদের আশ্বাস দেওয়া দরকার যে আমাদের কোনও পরিষেবার অভ্যন্তরে কলটি করা হয়েছিল, তা বোঝায় যে একটি লাইভ লেনদেনের অস্তিত্ব থাকা উচিত; অন্যথায় একটি ব্যতিক্রম occurs.Therefore প্রসারণ ধরনের হয় বাধ্যতামূলক ।
বিচ্ছিন্নতা স্তরটি নির্ধারণ করে যে কোনও লেনদেনের মাধ্যমে কিছু ডেটা সংগ্রহস্থলগুলিতে করা পরিবর্তনগুলি একই সাথে অন্যান্য যুগপত সাম্প্রতিক লেনদেনগুলিকে কীভাবে প্রভাবিত করে এবং কীভাবে এবং কখন সেই পরিবর্তিত ডেটা অন্যান্য লেনদেনের জন্য উপলব্ধ হয়। যখন আমরা স্প্রিং ফ্রেমওয়ার্ক ব্যবহার করে কোনও লেনদেনকে সংজ্ঞায়িত করি তখন আমরা কনফিগার করতে সক্ষম হয় যে একই লেনদেনটি কার্যকর করা হবে ola
@Transactional(isolation=Isolation.READ_COMMITTED)
public void someTransactionalMethod(Object obj) {
}READ_UNCOMMITTED বিচ্ছিন্নতা স্তরে বলা হয়েছে যে কোনও লেনদেন এমন ডেটা পড়তে পারে যা এখনও অন্য লেনদেনের দ্বারা অনুমোদিত নয়।
READ_COMMITTED বিচ্ছিন্নতা স্তরে বলা হয়েছে যে কোনও লেনদেন এমন ডেটা পড়তে পারে না যা এখনও অন্য লেনদেন দ্বারা প্রতিশ্রুতিবদ্ধ হয় না।
REPEATABLE_READ বিচ্ছিন্নতার স্তরে বলা হয়েছে যে কোনও লেনদেন যদি ডাটাবেস থেকে একাধিকবার একটি রেকর্ড পড়ে থাকে তবে এই সমস্ত পাঠ্য ক্রিয়াকলাপের ফলাফল সর্বদা একই হতে হবে।
গুরুতর বিচ্ছিন্নতা স্তর সমস্ত বিচ্ছিন্নতা স্তরের সীমাবদ্ধতম। লেনদেনগুলি সমস্ত স্তরে লকিং দিয়ে চালানো হয় (পড়ুন, ব্যাপ্তি করুন এবং রাইটিং লকিং করুন) যাতে তারা প্রদর্শিত হয় যেন তারা সিরিয়ালযুক্ত উপায়ে কার্যকর করা হয়েছিল।
যৌক্তিক বা শারীরিক লেনদেনের ক্ষেত্রে ব্যবসায়ের পদ্ধতিগুলি কীভাবে আবশ্যক তা সিদ্ধান্ত নেওয়ার ক্ষমতা প্রচার ।
বসন্তের প্রয়োজনীয় আচরণের অর্থ হ'ল বর্তমান বিন পদ্ধতি প্রয়োগের প্রসঙ্গে যদি ইতিমধ্যে খোলা লেনদেন হয় তবে একই লেনদেনটি ব্যবহৃত হবে।
REQUIRES_NEW আচরণের অর্থ হ'ল ধারক দ্বারা সর্বদা একটি নতুন শারীরিক লেনদেন তৈরি করা হবে।
নেস্টেড আচরণটি একই শারীরিক লেনদেনটি ব্যবহারের জন্য নেস্টেড স্প্রিং লেনদেনগুলিকে তৈরি করে তবে নেস্টেড আহ্বানের মধ্যে সেভপয়েন্টগুলি সেট করে যাতে অভ্যন্তরীণ লেনদেনগুলিও বাইরের লেনদেনের ক্ষেত্রে স্বাধীনভাবে রোলব্যাক করতে পারে।
জবাবদিহিতা আচরণ বলে যে একটি বিদ্যমান খোলা লেনদেন ইতিমধ্যে বিদ্যমান থাকতে হবে। ব্যতিক্রম না হলে ধারক দ্বারা নিক্ষেপ করা হবে।
নেভারের আচরণটি বলে যে একটি বিদ্যমান খোলার লেনদেন ইতিমধ্যে বিদ্যমান থাকতে হবে। কোনও লেনদেন উপস্থিত থাকলে একটি ব্যতিক্রম ধারক দ্বারা নিক্ষেপ করা হবে।
NOT_SUPPORTED আচরণ যে কোনও লেনদেনের সুযোগের বাইরে কার্যকর করবে। যদি খোলা লেনদেন ইতিমধ্যে বিদ্যমান থাকে তবে এটি বিরতি দেওয়া হবে।
সাপোর্টস আচরণটি যদি কোনও খোলা লেনদেন ইতিমধ্যে বিদ্যমান থাকে তবে কোনও লেনদেনের সুযোগে কার্যকর করা হবে। যদি ইতিমধ্যে খোলা কোনও লেনদেন না হয় তবে পদ্ধতিটি যাইহোক কার্যকর করা হবে তবে অ-লেনদেনের উপায়ে।
একটি লেনদেন একটি ডাটাবেস সহ কাজের একককে উপস্থাপন করে।
বসন্ত TransactionDefinitionইন্টারফেসে যা বসন্ত-অনুগত লেনদেনের বৈশিষ্ট্যগুলি সংজ্ঞায়িত করে। @Transactionalটীকাগুলি কোনও পদ্ধতি বা শ্রেণিতে লেনদেনের বৈশিষ্ট্যগুলি বর্ণনা করে।
@Autowired
private TestDAO testDAO;
@Transactional(propagation=TransactionDefinition.PROPAGATION_REQUIRED,isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED)
public void someTransactionalMethod(User user) {
// Interact with testDAO
}প্রচার (প্রজনন): আন্তঃ লেনদেনের সম্পর্কের জন্য ব্যবহৃত হয়। (জাভা আন্ত থ্রেড যোগাযোগের সাথে সাদৃশ্য)
+-------+---------------------------+------------------------------------------------------------------------------------------------------+
| value | Propagation | Description |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+
| -1 | TIMEOUT_DEFAULT | Use the default timeout of the underlying transaction system, or none if timeouts are not supported. |
| 0 | PROPAGATION_REQUIRED | Support a current transaction; create a new one if none exists. |
| 1 | PROPAGATION_SUPPORTS | Support a current transaction; execute non-transactionally if none exists. |
| 2 | PROPAGATION_MANDATORY | Support a current transaction; throw an exception if no current transaction exists. |
| 3 | PROPAGATION_REQUIRES_NEW | Create a new transaction, suspending the current transaction if one exists. |
| 4 | PROPAGATION_NOT_SUPPORTED | Do not support a current transaction; rather always execute non-transactionally. |
| 5 | PROPAGATION_NEVER | Do not support a current transaction; throw an exception if a current transaction exists. |
| 6 | PROPAGATION_NESTED | Execute within a nested transaction if a current transaction exists. |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+বিচ্ছিন্নতা: ডাটাবেস লেনদেনের এসিডি (পারমাণবিকতা, ধারাবাহিকতা, বিচ্ছিন্নতা, স্থায়িত্ব) বৈশিষ্ট্যগুলির মধ্যে বিচ্ছিন্নতা একটি। বিচ্ছিন্নতা নির্ধারণ করে যে কীভাবে লেনদেনের অখণ্ডতা অন্যান্য ব্যবহারকারী এবং সিস্টেমের কাছে দৃশ্যমান। এটি রিসোর্স লকিং অর্থাত্ কনসুকেন্সি কন্ট্রোলের জন্য ব্যবহার করে, নিশ্চিত করুন যে কেবলমাত্র একটি লেনদেন একটি নির্দিষ্ট পর্যায়ে সংস্থানটি অ্যাক্সেস করতে পারে।
লকিং উপলব্ধি: বিচ্ছিন্নতা স্তরটি লকগুলি অনুষ্ঠিত হওয়ার সময়কাল নির্ধারণ করে।
+---------------------------+-------------------+-------------+-------------+------------------------+
| Isolation Level Mode | Read | Insert | Update | Lock Scope |
+---------------------------+-------------------+-------------+-------------+------------------------+
| READ_UNCOMMITTED | uncommitted data | Allowed | Allowed | No Lock |
| READ_COMMITTED (Default) | committed data | Allowed | Allowed | Lock on Committed data |
| REPEATABLE_READ | committed data | Allowed | Not Allowed | Lock on block of table |
| SERIALIZABLE | committed data | Not Allowed | Not Allowed | Lock on full table |
+---------------------------+-------------------+-------------+-------------+------------------------+উপলব্ধি পড়ুন: নিম্নলিখিত 3 ধরণের বড় সমস্যা দেখা দেয়:
UPDATES অন্য টিএক্স থেকে ।INSERTSএবং / অথবা DELETESঅন্য কোনও টিএক্স থেকে পড়াবিভিন্ন ধরণের পাঠ সহ বিচ্ছিন্নতা স্তর:
+---------------------------+----------------+----------------------+----------------+
| Isolation Level Mode | Dirty reads | Non-repeatable reads | Phantoms reads |
+---------------------------+----------------+----------------------+----------------+
| READ_UNCOMMITTED | allows | allows | allows |
| READ_COMMITTED (Default) | prevents | allows | allows |
| REPEATABLE_READ | prevents | prevents | allows |
| SERIALIZABLE | prevents | prevents | prevents |
+---------------------------+----------------+----------------------+----------------+এটি প্রায়শই কখনও ব্যবহার করতে চান না Read Uncommitedকারণ এটি সত্যিই ACIDঅনুগত নয়। Read Commmitedএকটি ভাল ডিফল্ট শুরু জায়গা। Repeatable Readসম্ভবত শুধুমাত্র রিপোর্টিং, রোলআপ বা সমষ্টি পরিস্থিতিতে প্রয়োজন। নোট করুন যে অন্তর্ভুক্ত অনেক ডিবি, পোস্টগ্রিজ আসলে পুনরাবৃত্তযোগ্য পাঠকে সমর্থন করে না, Serializableপরিবর্তে আপনাকে ব্যবহার করতে হবে। Serializableযে জিনিসগুলি আপনি জানেন সেগুলির জন্য দরকারী যা অন্য যে কোনও কিছুর থেকে সম্পূর্ণ স্বাধীনভাবে ঘটতে হবে; synchronizedজাভা মত এটি মনে । সিরিয়ালাইজবল REQUIRES_NEWপ্রচারের সাথে একসাথে যায় ।
আমি REQUIRESআপডেট বা চালিত ক্যোয়ারির পাশাপাশি "পরিষেবা" স্তরের ফাংশনগুলি চালিত সমস্ত ফাংশনের জন্য ব্যবহার করি । ডিএও স্তর স্তরের ফাংশনগুলির জন্য যা কেবলমাত্র সেফেক্টগুলি চালিত করে, আমি ব্যবহার করি SUPPORTSযা কোনও টিএক্সে অংশ নেবে যদি কোনও ইতিমধ্যে শুরু হয় (যেমন কোনও পরিষেবা ফাংশন থেকে ডাকা হচ্ছে)।
লেনদেনের বিচ্ছিন্নতা এবং লেনদেনের প্রচার যদিও সম্পর্কিত তবে স্পষ্টত দুটি খুব ভিন্ন ধারণা ts উভয় ক্ষেত্রেই ক্লায়েন্টের সীমানা উপাদানগুলিতে ডিফল্টিকাল লেনদেন পরিচালনা বা প্রোগ্রামেটিক লেনদেন পরিচালনা ব্যবহার করে ডিফল্ট কাস্টমাইজ করা হয় । প্রতিটি বিচ্ছিন্নতা স্তর এবং প্রচারের বৈশিষ্ট্যগুলির বিশদ নীচে রেফারেন্স লিঙ্কগুলিতে পাওয়া যাবে।
একটি ডাটাবেসে দুটি বা ততোধিক চলমান লেনদেন / সংযোগের জন্য, কোনও লেনদেনে প্রশ্নগুলি দ্বারা কীভাবে এবং কখন পরিবর্তনগুলি করা হয় / আলাদা লেনদেনের প্রশ্নের কাছে দৃশ্যমান। এটি অন্যান্য লেনদেন এবং তদ্বিপরীত থেকে এই লেনদেনের পরিবর্তনগুলি বিচ্ছিন্ন করতে কোন ধরণের ডাটাবেস রেকর্ড লক ব্যবহার করা হবে তা সম্পর্কিত related লেনদেনে অংশ নিচ্ছে এমন ডাটাবেস / সংস্থান দ্বারা এটি সাধারণত প্রয়োগ করা হয়।
।
কোনও প্রদত্ত অনুরোধ / প্রক্রিয়াজাতকরণের জন্য একটি এন্টারপ্রাইজ অ্যাপ্লিকেশনটিতে অনেকগুলি উপাদান রয়েছে যা কাজটি সম্পাদনের জন্য জড়িত। এই উপাদানগুলির মধ্যে কিছু লেনদেনের সীমানা (শুরু / শেষ) চিহ্নিত করে যা সংশ্লিষ্ট উপাদান এবং এর উপ উপাদানগুলিতে ব্যবহৃত হবে। উপাদানগুলির এই লেনদেনের সীমানার জন্য, লেনদেনের প্রবর্তন নির্দিষ্ট করে যে কোনও উপাদান ইতিমধ্যে লেনদেনে অংশ নেবে না বা অংশ নেবে না এবং কলিং উপাদানটিতে ইতিমধ্যে তৈরি / শুরু হওয়া কোনও লেনদেন না থাকলে কী ঘটে happens এটি জাভা ইই লেনদেনের বৈশিষ্ট্যের মতো। এটি সাধারণত ক্লায়েন্টের লেনদেন / সংযোগ পরিচালক দ্বারা প্রয়োগ করা হয়।
রেফারেন্স:
আমি চালিয়েছি outerMethod, method_1এবং method_2বিভিন্ন প্রচারের মোড দিয়ে।
নীচে বিভিন্ন প্রচার মোডের আউটপুট দেওয়া আছে।
বাইরের পদ্ধতি
@Transactional
@Override
public void outerMethod() {
customerProfileDAO.method_1();
iWorkflowDetailDao.method_2();
}Method_1
@Transactional(propagation=Propagation.MANDATORY)
public void method_1() {
Session session = null;
try {
session = getSession();
Temp entity = new Temp(0l, "XXX");
session.save(entity);
System.out.println("Method - 1 Id "+entity.getId());
} finally {
if (session != null && session.isOpen()) {
}
}
}Method_2
@Transactional()
@Override
public void method_2() {
Session session = null;
try {
session = getSession();
Temp entity = new Temp(0l, "CCC");
session.save(entity);
int i = 1/0;
System.out.println("Method - 2 Id "+entity.getId());
} finally {
if (session != null && session.isOpen()) {
}
}
}আমরা এটির জন্য যুক্ত করতে পারি:
@Transactional(readOnly = true)
public class Banking_CustomerService implements CustomerService {
public Customer getDetail(String customername) {
// do something
}
// these settings have precedence for this method
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void updateCustomer(Customer customer) {
// do something
}
}আপনি এটির মতো ব্যবহার করতে পারেন:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public EventMessage<ModificaOperativitaRapporto> activate(EventMessage<ModificaOperativitaRapporto> eventMessage) {
//here some transaction related code
}আপনি এই জিনিসটি ব্যবহার করতে পারেন:
public interface TransactionStatus extends SavepointManager {
boolean isNewTransaction();
boolean hasSavepoint();
void setRollbackOnly();
boolean isRollbackOnly();
void flush();
boolean isCompleted();
}