[ZODB-Dev] strange synchronization bug

[Nicholas Henke]

Here is the output from A and B that shows the bug:

A:
bash-2.05a$ python test_add.py
test: <DummyClass instance at 8217ee8>, test.attr: 2
test: <DummyClass instance at 8217ee8>, test.attr: 3
test: <DummyClass instance at 8217ee8>, test.attr: 4
bash-2.05a$ python test_add.py
test: <DummyClass instance at 817bc48>, test.attr: 6
bash-2.05a$ python test_add.py
test: <DummyClass instance at 8217ee0>, test.attr: 7
test: <DummyClass instance at 8217ee0>, test.attr: 8
test: <DummyClass instance at 8217ee0>, test.attr: 9
test: <DummyClass instance at 8217ee0>, test.attr: 10
test: <DummyClass instance at 8217ee0>, test.attr: 11
test: <DummyClass instance at 8217ee0>, test.attr: 12


B:
bash-2.05a$ python test_watch.py
test: <DummyClass instance at 82167c0>, test.attr: 4
test: <DummyClass instance at 82167c0>, test.attr: 4
test: <DummyClass instance at 82167c0>, test.attr: 4
bash-2.05a$ python test_watch.py
test: <DummyClass instance at 82167c0>, test.attr: 7
test: <DummyClass instance at 82167c0>, test.attr: 7
test: <DummyClass instance at 82167c0>, test.attr: 7
test: <DummyClass instance at 82167c0>, test.attr: 7
test: <DummyClass instance at 82167c0>, test.attr: 7
test: <DummyClass instance at 82167c0>, test.attr: 7


Nic
-- 
Nicholas Henke
Linux cluster system programmer
University of Pennsylvania
henken@seas.upenn.edu - 215.573.8149

On Thu, 29 Aug 2002, Nicholas Henke wrote:

> Hey all -- Attached is a tarball containing a very stripped down version
> of the database layers I am using. I tried to make the test case a
> simple as possilbe. I am using StandaloneZODB from cvs as of yesterday.
>
> The bug I am encountering is:
>
> A connects via unix socket /tmp/clubmask.zeo to a ZEO server and updates
> root['clubmask']['test'].attr += 1. A is able to increment the value of
> attr with no problems, and will do so forever...
>
> B connects via same socket to same server and polls value of test.attr. B
> will _never_ see the changes that A is making to test.attr. B will just
> see the value that is read the first iteration. If B is killed and
> restarted, it will see a new value for test.attr on the first read, but
> after that fails to see the updates.
>
> I am committing the database in A, but other than that I have no idea on
> how to force A to tell B that the data has changed -- shouldn't ZEO do
> this automagically? I would much appreciate any and all help :)
>
> Nic
>
>