> > That said, the goal is of course not to make the developer's life > miserable. All the driver wants is an acknowledgement that the error > was perceived and taken care of. This is done trivially by calling: > > session.Refresh() >
So in Juju now, we use session.Copy() which calls Refresh() under the hood. We do this for each database interaction. It's not too onerous. > Done. The driver will happily drop the error notice, and proceed with > further operations, blocking if waiting for a re-election to take > place is necessary. > > > This feels very much like a concurrency or timing issue. You might > also be misunderstanding what session.Copy does.. it's not so magic. > If session.Copy truly prevented the watcher from working, it wouldn't > work at all either way. Every independent process that connects to the > database and does a change is monitored by watchers that live in > different sessions. > >> The tests are quite simple: > > I'm not able to observe the test failure you mention after hacking it > to use independent sessions: > > http://paste.ubuntu.com/7852418/ > The tests passed for me every time also, with and without independent sessions. If I loaded my machine to max out CPU usage to 100%, then the tests (different ones each run) would fail intermittently but reproducibly every time with session copy, but I could not induce even one failure without session copying. Maybe the watcher implementation is indeed somehow involved. I'm not 100% across any subtleties in the implementation as till a few days ago the code was new to me. I am interested in being able to explain how session.Copy() does observably affect the test results and relate that to a defect in the code so it can be fixed. But I don't know how to explain that right now. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
