Hi Mike, Thanks for your reply. In my case, the full_name attribute is a hybrid property using query on firstName and lastName. When I construct a Person instance, I need a session to query the names and build the full_name attribute on the fly. So do you think I should remove this session immediately after I have built full_name attribute? What if later on my application changes this person's firstName? If the session is still alive it will expire full_name attribute automatically, but if the session was removed, there won't be any automatic update on those hybrid_property, right?
Doesn't this scenario justify a background thread? On Sat, Jun 28, 2014 at 7:14 AM, Mike Bayer <mike...@zzzcomputing.com> wrote: > > 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 a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/CVIkd-WQiDM/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- 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.
