If you just throw two transactions in a thread pool, you may or may not get
an exception since one transaction may have completed before the other
transaction begins. To deterministically make one transaction fail, you
have to ensure that both threads have read the initial value and have made
change to the original value before either transaction commits.
region.put("K", "V");
CountDownLatch latch1 = new CountDownLatch(1);
CountDownLatch latch2 = new CountDownLatch(1);
Thread th1 = new Thread(() -> {
mgr.being();
region.put("K", "V1");
latch1.countDown();
latch2.await();
mgr.commit();
});
Thread th2 = new Thread(() -> {
mgr.begin();
region.put("K", "V2");
latch1.await();
latch2.countDown();
mgr.commit();
});
th1.start();
th2.start();
On Thu, Oct 18, 2018 at 10:28 AM Dharam Thacker <[email protected]>
wrote:
> Hello Team,
>
> I am trying to understand *transaction behavior* with apache geode. I
> have created a simple demo as attached here in with this email.
> It's a simple spring data geode application with apache geode 1.6.0
>
> Spring Startup Listener class >> SimpleApplicationListener .java
> Service class >> CustomerService.java
>
> 2 thread are simultaneously trying to update customer=1234 by changing
> name from [Thread-T1 - (From A1->To A2)] and [Thread-T2 - (From A1->To A3)]
> I assume that at least 1 thread has stale copy of data and should throw
> commit conflict exception but I think I am missing something and it's not
> behaving as expected.
>
> Could some one help me to understand what I am missing here?
> [Attached tar.gz file]
>
> Thanks & Regards,
> - Dharam Thacker
>
