>> Well, there's a difference between "not working" and "failing".
>> :-)
>>
>> This error will force the application to abort a transaction,
>> or a non-transactional read will fail, returning an error. The
>> system as a whole will continue to work correctly. (If the
>> application was doing non-transactional database modifications,
>> of course, it might not be able to recover, but that's why it's
>> using transactions in the first place, to handle these kinds of
>> failure without having to halt the system.)
>
> If that's the case how come when people end up getting these out of
> memory failures the problem doesn't simply resolve itself when usage of
> the repository goes down to a more reasonable level? I'm not positive,
> but if I recall correctly people generally have to run recovery before
> things start working again.
That should not happen -- Berkeley DB should absolutely survive
reaching any resource limit (other than heap memory), including
cache space or filesystem space. If Subversion can reproduce this
failure we are very, very interested in hearing about it.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic@sleepycat.com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 8 22:11:42 2004