On Jan 7, 2011, at 2:15 AM, Russ wrote: > I'm running into some issues with objects being attached to sessions > that I don't quite understand. > > Basically, if I create some objects, add them to a session, commit, > then turf the session (or at least let it fall out of scope), one > expectation I have is that I will still be able to access the basic > properties on the object without a DB connection.
If properties have been expired or were not yet loaded, they require an active database connection. Your mapped objects represent database rows within an active transaction, and should be considered an extension of the Session's own state. This is discussed to some degree in http://www.sqlalchemy.org/docs/orm/session.html#frequently-asked-questions . Why might the attributes be expired ? Usually, because a commit() has been called, which expires all attributes. Rationale + options to disable: http://www.sqlalchemy.org/docs/orm/session.html#committing > > I also ran into some cases where attribute access was 'mysteriously' > working for some objects and not others after the session was deleted > (or dropped out of scope). I have since determined that it is because > the associated sessions that I had thought were completely gone had > simply not been garbage collected yet and were still performing their > duties!! This sounds like you have sloppy management of your sessions going on, and therefore sloppy management of transactions. The recommended usage of a Session is to frame the scope in which you are working with a set of objects. Your application is a banquet; each thread is a guest; the collection of Sessions are the plates; your mapped objects are the entree. The only use cases for "detached" objects are those loaded from an external cache, or which are being sent over some kind of serialized stream such as when using multiprocessing. In these cases the objects should be immediately re-associated with a Session, usually via Session.merge() or sometimes Sesssion.add(). > > I'm not a gc expert by any means, but thought the lingering session > might have something to do with the weak reference the session has on > contained objects. weak references have no impact on garbage collection - they don't count as references regarding GC. > I was wrong. I tried the sessionmaker's > 'weak_identity_map = False' option and it had no impact. That option is intended to provide a Session that holds strongly onto its contained objects, and has no real use case today. It will eventually be removed. > What is > confusing is the reverse direction... that the objects still have > usable references to the deleted sessions. There are no strong references to the Session in SQLAlchemy itself. The Session usually has cycles within it which would prevent so-called "immediate gc" from occurring, however in Python its considered extremely poor practice to rely upon "immediate gc" to clean up references as that is a behavior idiosyncratic to current CPython implementations only. The correct way to close out the connection and transaction resources and disassociate all objects held by a Session is to call Session.close(): http://www.sqlalchemy.org/docs/orm/session.html#closing -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
