Chris McDonough wrote:
> On Mon, 2003-03-17 at 20:34, John Eikenberry wrote:
> > The KeyErrors happen under similar circumstances to the ReadConflictErrors.
> > The significant difference being that the KeyErrors happen after the
> > transience timeout has occured. When I am running with the
> > L
On Tue, 2003-03-18 at 14:01, Toby Dickenson wrote:
> On Tuesday 18 March 2003 6:12 pm, Chris McDonough wrote:
> > I'm
> > thinking that I also may just need to move the housekeeping duties to a
> > separate scheduled thread that only happens when the system is "not
> > busy" (e.g. when the asyncore
On Tuesday 18 March 2003 6:12 pm, Chris McDonough wrote:
> I'm
> thinking that I also may just need to move the housekeeping duties to a
> separate scheduled thread that only happens when the system is "not
> busy" (e.g. when the asyncore poll select timeout is reached maybe) in
> order to reduce t
> Today you are guaranteed that your transaction reads a consistent initial
> state of A and B. That is, there is no chance that you only see half the
> changes of a recent transaction that modified both.
>
> Yes, it is possible for one transaction to modify A and a concurrent
> transaction to
On Tuesday 18 March 2003 3:24 pm, Chris McDonough wrote:
> > Our live sessions code uses the sessions about half to two-thirds of the
> > way through the transaction. Given what can happen in that first half,
> > there is easily plenty of time for read conflicts. I think I might be
> > able to mov
On Mon, 2003-03-17 at 20:34, John Eikenberry wrote:
> John Eikenberry wrote:
>
> > Toby Dickenson wrote:
> >
> > > Read conflicts occur if a change is committed in between the start of a
> > > transaction, and the transaction needing to load the object. A workaround to
> > > reduce the number o
