Yeah I understand; so introducing a read write lock should address this
does it not? One writer has reached commit and is trying to obtain a write
lock no further readers are let out. We have to wait for then to settle
down and complete before the commit can proceed.
That is we need to wait on th
Hi Jody,
I think we agree on the two transaction case, what is giving me more
trouble right now is the lack of isolation between
readers got out of transaction and writers committing a transaction,
leaving readers (temporarily) going over a corrupted file.
Cheers
Andrea
On Fri, Dec 7, 2018 at 8:
Makes sense, think we arrived at the same spot (narrowing the conflict down
to the commit). The comment about responsibility for readers and writers
was with respect to encapsulation (because it is response we can fix it one
location).
It is just hard to talk clearly about this as we have two leve
On Fri, Dec 7, 2018 at 6:42 PM Jody Garnett wrote:
> Yeah I am aware of the gap, we did not implement a two phase commit.
>
> Can we introduce those read/write locks into TransacationStateDiff? I
> thought the object was already responsible for producing reader and writer
> wrappers which should
Yeah I am aware of the gap, we did not implement a two phase commit.
Can we introduce those read/write locks into TransacationStateDiff? I
thought the object was already responsible for producing reader and writer
wrappers which should give us a clean way to do it?
For clarity we “only” need to o
Hi,
I am looking at removing a read/write found in the image mosaic, which
guards all read/write operations
against GeoTools data stores, so that no to writes can occur in parallel,
and no writes can occur in parallel
with reads.
My first reaction was "hey, datastores can already handle this, why
