Open Stack

Hello,

Just a follow up in case someone hits the mailing list archive looking
for info related to this issue, this change seems to fix the problem:

https://review.openstack.org/#/c/57019/

"When concurrent PUT requests come in for an account or container, the
resulting DB access will try to lock the DB for writing. Normal access
will retry when it encounters a locked DB, change 0fdad0d9 introduced
a cursor for doing the initialization which did not have the retry
capability, resulting in a hard failure."

It's related to this bug report:
https://bugs.launchpad.net/swift/+bug/1243973

Regards,

Juan

On 14/11/13 17:09, Pete Zaitcev wrote:
> On Thu, 14 Nov 2013 14:18:37 +0000
> "Juan J. Martinez" <juan at memset.com> wrote:
> 
>> I've managed to isolate the change that introduced the problem:
>>
>> https://github.com/openstack/swift/commit/0fdad0d9d9e68b00f61171bb2a0dfd840ef5345f
>>
>> As this change is just for PyPy support I've reverted it and the problem
>> is gone.
>>
>> Unfortunately I can't really explain why.
>>
>> According to sqlite3 docs [1], *execute* method in the connection is
>> creating a cursor, but it looks like the cursor created explicitly is
>> doing something differently (at least in Python 2.6 running on Squeeze),
>> because I got rid of the OperationalError (database is locked) errors.
> 
> Interesting. I don't have a clue either. Peter is going to poke Alex
> about this, but ultimately we have to figure it out.
> 
> -- Pete
> 


-- 
Juan J. Martinez
Software Developer, MEMSET

mail: juan at memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey GU6 8TB, UK.