On 6/28/14, 7:13 AM, Bao Niu wrote: > My situation is like this: > > I am developing a web application, which has a Person class, which has > /FirstName/ and /LastName/ attributes. Now I want to build their full > name attribute and make this /full_name/ attribute queriable, by using > hybrid_property, which entails query and hence session. This session > for querying hybrid_property has its life cycle as long as that > particular Person instance is active in memory, as in the running > process the names might get changed, and need to communicate to the > database. > > In the mean time, in this application I also need another Session > instance to contain those Person instances themselves, and this > Session instance has a quite different life cycle than the above one. > I am using cherrypy.request to hold a thread-local session for this > second purpose. > > Now it seems to me that both Session instances are necessary, I can't > use one in place of the other. But because handling two sessions at > the same time is inherently so confusing sometimes, I wonder if I am > in the right direction? Is this generally considered bad? If it is, > then how to deal with it? Thanks in advance.
If this is a web application, having a session that isn't lifecycled to a request seems like it runs in some kind of background thread or something. Otherwise, if its some session that stays open in the cherrypy app while the app is doing nothing, and is only used by requests (somehow? session shouldn't be accessed by multiple things at once) not serving requests, that's bad. if you're using a Session as some kind offline cache, that's not what it's for and it won't do a good job of that because it isn't threadsafe. think more in terms of database transactions. I use two sessions all the time when I want to separate transactions, a background job is working in a transaction for several seconds, but a second short transaction is used to write messages to a log table, so that I can see the log table grow from the outside while the long transaction keeps going. But database transactions overall should be short, and never dormant waiting for something to happen, they should be burning through the work they have to do as fast as possible and completing. So should your sessions. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
