Ah, ok thanks for clarifying. I will leave my ticket unassigned ср, 31 мая 2017 г. в 21:10, Alexey Goncharuk <alexey.goncha...@gmail.com>:
> Aleksey, > > Generally, this decision cannot be made on a single node because a > transaction may affect multiple nodes, and one node may have already > committed the transaction and the other - not. There is a dependant ticket > in the ticket you are currently working on which will cover all the caes. > > Meanwhile, an easy way to verify reads is to start an optimistic > serializable read-only transaction and commit it after reads. A commit will > throw OptimisticException if you happen to read an inconsistent set of > values. > > 2017-05-31 19:57 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > one possible solution is to lock entry reading section while userCommit() > > method is executing. > > > > ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > > > Hi, Igntrs! > > > When the first writer thread has commited values and cache entries are > > > getting updated with this new values, another thread is getting > partially > > > assigned values through the > > > > > > cache.getAll(keys) > > > > > > should this method wait for all newly updated entries to finish , or > > > should it throw the exception? > > > > > > If it should wait for entries, what mechanism shall i implement? would > > > appreciate any examples > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > -- *Best Regards,* *Kuznetsov Aleksey*
