What you are suggesting is definitely not what I think of as the traditional pattern for a web application (but I don't know exactly what you are trying to do, so perhaps you have good reasons for doing things this way).
In the web applications that I write, there is no real state on the server in between requests, except what is stored in the database. So when a web request comes in, a new sqlalchemy session is created, the data is loaded from the database, any necessary changes are made, the data is flushed back to the database, and the session is closed. There is never any need for data to be held in memory on the server between web requests. >From what you've written, it sounds like you might perhaps be confusing the concept of "web sessions" with "database sessions". "web sessions" are a mechanism for identifying a single user, and the actions they are performing, across multiple web requests. They are typically implemented using cookies, where the cookie can either contain the session data itself, or it can contain a key to a set of data in the database. However, they have nothing to do with SQLAlchemy sessions. (I'm also a bit confused by your mention of hybrid_property. As far as I'm concerned, hybrid_property is just a convenient mechanism to help you avoid writing "self.FirstName + ' ' + self.LastName" everywhere, even in queries) Simon On Mon, Jun 30, 2014 at 11:28 AM, Bao Niu <niuba...@gmail.com> wrote: > Hi Simon, > Sorry for the poor explanation in my previous post. > Let me try to clarify this using a flow here: > ------------------------------------------------------------------------------- > 1st_web_request comes in to tell the server which person instances are to be > interested. because it involves hybrid_property, and query, so it needs a > session here, let's call it session_#1; > ==> > entering a stage where session_#1 has to be active, or otherwise we will > lose sync ability to update those hybrid_property. At this stage session_#1 > basically is just holding a bunch of queried associations of Person > instances and their names, and standing by, waiting for any update of > FirstName or LastName to construct a new hybrid_property of Full_Name on the > fly. > ==> > Now we have 2nd_web_request coming in, which carries a thread-local session > object of its own, let's call it collectively session_#2.(by the way I'm > using cherrypy and built a plugin and tool to automatically bind a session > for each request) I plan to use this second session object(s) to hold a > bunch of Person(not just their names, in comparison to session_#2). > > My design breaks down here, as I really am lost in how I can deal with two > differently cycled session objects. Or maybe this design itself is flawed? > Maybe I there is something I missed about session as a whole? > > > On Mon, Jun 30, 2014 at 2:57 AM, Simon King <si...@simonking.org.uk> wrote: >> >> I'm not sure I understand your application. Are you saying that you >> have Person instances that stay in memory for longer than a single web >> request? >> >> Simon >> >> On Sun, Jun 29, 2014 at 11:54 AM, Bao Niu <niuba...@gmail.com> wrote: >> > 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. >> >> -- >> 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. -- 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.
