your best option is probably to keep the objects in a session that's specifically for the "global" objects. Most important is that if you are using multiple threads, you never call flush() on this session. With regards to threadsafety in this case, as long as the session is not used for a flush() operation, you should be OK. The connection used for querying for a non-transactional session is checked out distinctly per-operation, so there will be no conflicts there. The second place of concern is when the Query retrieves existing objects from the identity map as it loads rows, and as it places newly loaded objects into the identity map; multiple threads might both create the same object and might both store it in the identity map; only one would actually remain in the map. However for a purely read-only situation, your application will still see the same kinds of objects, and even the object that was "replaced", which still would remain established in a parent collection, can still call upon that session to issue further lazyloads.
I might look into adding a flag in 0.4 session "readonly", which produces a session that disallows flush() and places a single mutex around query.instances(); then youd have a completely threadsafe read- only session. its only a couple of lines. On Jul 28, 10:09 am, MuTPu4 <[EMAIL PROTECTED]> wrote: > One of my tables represents a tree structure which I want to be cached > in memory during my application's lifetime. Problem is that i can not > figure out how to organize sessions acquisition/releasing. I am > loading the whole hierarchy using one session and then closing it > which makes objects detached. Then duaring modifications and lazy > loads across relations I am getting an errors like: > InvalidRequestError: Parent instance <class > 'si.core.category.Category'> is not bound to a Session, and no > contextual session is established; lazy load operation of attribute > 'parent' cannot proceed > Creating a new session and reattaching existing objects to it using > update( ) helps but I hope that reattaching the whole hierarchy is not > the right way. Is there a way to keep permanent objects in memory > without holding initial session for the whole application lifetime? > > Sorry for my bad English. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
