Hi Dharam, If there are two requests that read and write the same entry, you can trust Geode to throw a CommitConflictException if the changes are going to overwrite one another. My above example will throw this exception. If that exception is not thrown, then your transactions actually happened one after the other, in which case the second transaction should be able to read the change made by the first transaction.
On Thu, Oct 18, 2018 at 11:30 AM Dharam Thacker <[email protected]> wrote: > 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 >>> >>
