Commit 52baf1e6 authored by Jim Fulton's avatar Jim Fulton

Updated for recent decisions and clasrified some things.

parent 594c8c9b
...@@ -226,8 +226,11 @@ T2 ...@@ -226,8 +226,11 @@ T2
B2 B2
Here, we avoid incorrect returned values and incorrect cache at the Here, we avoid incorrect returned values and incorrect cache at the
cost of caching nothing. For this reason, a future ZEO 4 revision cost of caching nothing.
will require ZODB 4 or earlier.
ZEO 4.2.0 addressed this by using the same locking strategy for
``loadBefore`` that was used for ``load``, thus mitigating B2 the
same way it mitigates T2.
ZEO 5 ZEO 5
----- -----
...@@ -252,16 +255,16 @@ asyncio's ``call_soon_threadsafe`` to send invalidations in a client's ...@@ -252,16 +255,16 @@ asyncio's ``call_soon_threadsafe`` to send invalidations in a client's
thread. This could easily cause invalidations to be sent after loads. thread. This could easily cause invalidations to be sent after loads.
As shown above, this isn't a problem for ZODB 5, at least assuming As shown above, this isn't a problem for ZODB 5, at least assuming
that invalidations arrive in order. This would be a problem for that invalidations arrive in order. This would be a problem for
ZODB 4. ZODB 4. For this reason, we require ZODB 5 for ZEO 5.
Note that this approach can't cause invalidations to be sent early, Note that this approach can't cause invalidations to be sent early,
because they could only be sent by the thread that's busy loading, so because they could only be sent by the thread that's busy loading, so
scenario 2 wouldn't happen. scenario 2 wouldn't happen.
To mitigate T1, we could create a thread-safe server-side message B2
queue that's used when sending results. Unfortunately, this puts us Because the server send invalidations by calling
back in the position of having to wake up the event loop again (via ``call_soon_threadsafe``, it's impoossible for invalidations to be
``call_soon_threadsafe``). Maybe that's OK. send while a load request is being handled.
The main server opportunity is allowing commits for separate oids to The main server opportunity is allowing commits for separate oids to
happen concurrently. This wouldn't effect the invalidation/load happen concurrently. This wouldn't effect the invalidation/load
...@@ -271,4 +274,3 @@ It would be nice not to block loads while making tpc_finish calls, but ...@@ -271,4 +274,3 @@ It would be nice not to block loads while making tpc_finish calls, but
storages do this anyway now, so there's nothing to be done about it storages do this anyway now, so there's nothing to be done about it
now. Storage locking requirements aren't well specified, and probably now. Storage locking requirements aren't well specified, and probably
should be rethought in light of ZODB5/loadBefore. should be rethought in light of ZODB5/loadBefore.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment