Thank you Swapnil! But how can we guarantee this?
I have a spring boot geode client as web app. It has several emdpoints to accept add/update/delete actions. If 2 users are trying to change same customer with undefined email as initial state in 2 different rest requests in almost same time, of course by reading original customer with no email and changing emails, how could this be ensured? It may happen that user1's transaction succeded due to many possible reasons, it's confirmed now that user2 has stale data and he will overwtite changes. Could you suggest how we can handle it? Thanks, Dharam On Thu, Oct 18, 2018, 23:46 Swapnil Bawaskar <[email protected]> wrote: > 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 >> >
