> i can only make comments about fragments like this but i cant address > your full design issue since you havent supplied a fully working > illustration of what it is youre trying to do.
the daemon: http://dpaste.com/hold/27089/ and required utils.py modele: http://dpaste.com/hold/27092/ it was running with revision 3863 > the biggest issue I > can see is that the code seems to have a weak notion of explicit > transaction boundaries...its opening many sessions, one per thread > (since youre using scoped_session), and just keeping them opened, with > just one commit() when a delete is issued and thats it. How to open one session for all threads ? Using Lock with inserts/ updates should help in this case, right ? > addtionally, youre > issuing some SQL directly to the database without notifying the > session about objects which may have been removed; > youre executing a SQL statement through sess.execute() but that has no > effect on the User object stored in the session..plain SQL executes > dont refresh or expire anything thats currently present in the > session. when you commit(), the underlying flush() apparently is > hitting that user, or perhaps a different one, and attempting to > update it. I was trying to represent this SQL statement in ORM: "DELETE FROM fs_file WHERE path='/' and user_id=<theone.id>". If I'd need to delete user I'll use session.query.delete(user), indeed. But how to perform writing operations in proper way then, without execute() ? I was looking, thinking, asking and thinking again but came to nithing yet ) > locking youre doing doesnt have much effect here, without more context > it seems like its not needed and is just adding to the confusion. I was thinking it will exclude few doubtfull assumption from my inspection list. > Its possible that you'd benefit here from using explciit transactions, > so that you dont need to be dependent on the Session in order to > commit raw SQL which youve executed. You can begin() and commit() > transactions using an Engine or a Connection...such as: > > conn = db.connect() > trans = conn.begin() > session = Session(bind=conn) > # do stuff with the conn, do stuff with session > trans.commit() But I see that sqlalchemy beginning transaction anyway > Transactions should be opened and closed for individual groups of > operations. For example, if your "arrange" thread starts up, performs > some work, and then completes, it should be opening a transaction and/ > or Session session != transaction ? the difference between them is presence in session of cache ? > strategy="threadlocal" are more than likely confusing the issue. removed. In fact cannot say that clearly understand what it does > scoped_session is going to accumulate sessions for every thread, even > if that thread has died out, which will certainly cause memory to grow > unbounded if you keep creating new threads. it would probably be > cleaner to have each arrange() thread keep track of its own Session > and transaction, which are disposed of when the thread completes. Thanks for the idea, I'll try to elaborate. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
