> [...] it's > not safe with *any* database to share a connection between multiple > simultaneous requests. > [...] > Sessions are intended to be a "unit of work", which maps nicely to > the notion of a request. To try to use them as a cache beyond a > single unit of work is dangerous, because you might get stale data > when you're not expecting it. OK for the shared connection, I was meaning "shared session" :) ... Actually, by "shared session", I mean "shared cache"... which is, as you said, not a good idea, or needs complex code to be synced between threads.
> We don't use the threadlocal mod. When using the 'threadlocal' mod, the engine strategy is defaulting to 'threadlocal', instead of 'plain'. From SA's doc: "Using this [threadlocal] style, an application will use only one connection per thread at most within the scope of all implicit executions.". Don't you think the 'threadlocal' strategy (not the threadlocal mod) is better suited for TG's apps ? When creating engines, TG doesn't specify the strategy. Is this by design so users can have the choice ? Do you have any recommendation about that ? > I punted on that for now. It's a less-common case, so it wasn't a > priority. TG 1.1 will let you have a different dburi for each > application, at the very least. OK, I'll have look on TG 1.1 when it's done. Thanks for your reply and advices. Cheers Seb -- Sébastien LELONG On Wednesday 27 September 2006 13:22, Kevin Dangoor wrote: > On Sep 26, 2006, at 5:13 AM, seb wrote: > > Looking at TG sources, I found that (if I understand well ...): > > - each CP's thread starts a new connection (create_engine) and binds > > metadata to the declared model, using a DynamicMetaData. This avoid > > having one shared connection. > > IIRC, the connections are pooled. If you're using transactions, it's > not safe with *any* database to share a connection between multiple > simultaneous requests. > > > - this can be done by using activemapper, which indirectly uses > > sqlalchemy.mods.threadlocal. This creates an thread-specific > > objectstore (session), which is used by the app to act on the db. > > - sessions are cleared once the CP's request is done, using CP filter > > (on_end_resource). > > We don't use the threadlocal mod. (Again, going by memory). TG just > makes sure to share the same connection stuff with Active Mapper so > that the user has a choice of which way to go. > > > Is there any other architecture that was relevant when TG has > > integrated SA ? > > Not that I recall. > > > How do you deal with multiple data sources (ie. multiple db ie. > > multiple dburi) ? > > I punted on that for now. It's a less-common case, so it wasn't a > priority. TG 1.1 will let you have a different dburi for each > application, at the very least. > > > Is there any way not to clear sessions, as it clears the SA's cache > > (identity_map) or is the performance is good enough to not caching > > objects ? > > Sessions are intended to be a "unit of work", which maps nicely to > the notion of a request. To try to use them as a cache beyond a > single unit of work is dangerous, because you might get stale data > when you're not expecting it. Either way, caching at this level is > completely application-dependent. > > Kevin > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
