Sorry, my post got garbled a bit!
What I meant to say was that changing the isolation_level to immediate
helped with the problem in that its more difficult (but not
impossible, of course) to get a deadlock error as before. However, now
I've run into a new problem. The details follow in my original post.
Regards, Matthew
On Nov 2, 6:51 pm, Matthew Newhook <[EMAIL PROTECTED]> wrote:
> I took your advice and duplicate the problem in a small python test
> app. Changing the isolation_level to immediate seems to help the
> problem, which is good!
>
> > task.mapper.save_obj(task.polymorphic_tosave_objects, trans)
>
> Module sqlalchemy.orm.mapper:1201 in save_obj
> ... some variables ...
> rec (<coffeeshop.models.CartItem object at 0x1a3b750>,
> {'cart_items_id': 12, 'quantity': 2}, <...;sqlalchemy.orm.map
> rows 0
> t table table_to_mapper update [(<coffeeshop.models.CartItem
> object at 0x1a3b750>, {'cart_items_id': 12, 'quantity':
> 2}, ...<sqlalchemy.orm.map
> per.Mapper object at 0x161b470>)]
> updated_objects set([<coffeeshop.models.CartItem object at
> 0x1a3b750>])
>
> <class 'sqlalchemy.exceptions.ConcurrentModificationError'>: Updated
> rowcount 0 does not match number of objects updated 1
>
> The SQL echo is:
>
> $ cat /f/t
> 2007-11-02 18:46:17,556 INFO sqlalchemy.engine.base.Engine.0x..b0
> BEGIN
> 2007-11-02 18:46:17,557 INFO sqlalchemy.engine.base.Engine.0x..b0
> SELECT cart_items.product_id AS cart_items_product_id,
> cart_items.price AS cart_items_price, cart_items.id AS cart_items_id,
> cart_items.cart_id AS cart_items_cart_id, cart_it
> ems.quantity AS cart_items_quantity
> FROM cart_items
> WHERE cart_items.id = ? ORDER BY cart_items.oid
> 2007-11-02 18:46:17,557 INFO sqlalchemy.engine.base.Engine.0x..b0
> [u'12']
> 2007-11-02 18:46:17,559 INFO sqlalchemy.engine.base.Engine.0x..b0
> COMMIT
> 2007-11-02 18:46:18,518 INFO sqlalchemy.engine.base.Engine.0x..b0
> UPDATE cart_items SET quantity=? WHERE cart_items.id =
> ?
> 2007-11-02 18:46:18,519 INFO sqlalchemy.engine.base.Engine.0x..b0 [2,
> 12]
> 2007-11-02 18:46:18,519 INFO sqlalchemy.engine.base.Engine.0x..b0
> ROLLBACK
> Debug at:http://192.168.2.34:5432/_debug/view/1194000220
>
> That doesn't look good! The code in question is something like:
>
> try:
> if c.cart.remove(id):
> c.cart.flush()
> transaction.commit()
> except:
> transaction.rollback()
> raise
>
> Its crapping out on the transaction.commit().
>
> Regards, Matthew
>
> On Nov 1, 11:39 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> > 1st step would be to ensure youre on the latest version of sqlite.
> > second step would be to create a test program illustrating the
> > behavior using pysqlite only (sqlalchemy doesn't have anything to do
> > with sqlite lock timeout issues). if you can confirm that the
> > timeout isnt working in that case, you can submit a bug report to
> > pysqlite and/or sqlite. the sqlite devs are *very* responsive to
> > issues.
>
> > On Nov 1, 2007, at 10:13 AM, Matthew Newhook wrote:
>
> > > I posted this message in the pylons group but as of yet have received
> > > no response.
>
> > >http://groups.google.com/group/pylons-discuss/browse_frm/thread/
> > > 093ec04b48e49c3c?hl=en#
>
> > > I've been looking into this problem a little more. From my reading of
> > > the SQLite documentation there should be a 5 second timeout by default
> > > (I'm using pysqlite 2.3.2). Looking at the source this looks correct.
> > > However, in testing my app when I get this exception there is
> > > definitely no 5 second timeout! It happens immediately. I also tried
> > > 500 seconds, and had no better luck. When I concurrently access my
> > > webapp I immediately get this exception.
>
> > > Also the exception confuses me. The 'database is locked' text
> > > indicates that the error is SQLITE_LOCKED which is documented as:
>
> > > SQLITE_LOCKED
>
> > > This return code is similar to SQLITE_BUSY in that it indicates
> > > that the database is locked. But the source of the lock is a recursive
> > > call to sqlite_exec. This return can only occur if you attempt to
> > > invoke sqlite_exec from within a callback routine of a query from a
> > > prior invocation of sqlite_exec. Recursive calls to sqlite_exec are
> > > allowed as long as they do not attempt to write the same table.
>
> > > However, the documentation indicates that I should be getting
> > > SQLITE_BUSY or IOERROR.
>
> > > Anyone have any ideas how to solve this problem?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
