Cache.getAll can return partially commited results. IGNITE-4809

[voipp]

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*

[voipp]

one possible solution is to lock entry reading section while userCommit()
method is executing.

ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV <[hidden email]>:

> 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*

[Alexey Goncharuk]

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 <[hidden email]>:

> one possible solution is to lock entry reading section while userCommit()
> method is executing.
>
> ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV <[hidden email]>:
>
> > 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*
>

[voipp]

Ah, ok thanks for clarifying. I will leave my ticket unassigned

ср, 31 мая 2017 г. в 21:10, Alexey Goncharuk <[hidden email]>:

> 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 <[hidden email]>:
>
> > one possible solution is to lock entry reading section while userCommit()
> > method is executing.
> >
> > ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV <[hidden email]>:
> >
> > > 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*