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.
