Hi Arnar, On 6/8/06, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > > Hi there, > > On 6/8/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > > Basic database support should not involve sessions. Sessions make > > scaling trickier, so I wouldn't want to apply sessions to something as > > basic as db access. Besides, you really don't want database > > connections getting stuck an on individual user anyhow > > I was talking about SA Session objects, not sessions in the "webapp" sense.
D'oh. Of course. > SA Sessions handle unit of work, each instance of a db-mapped object > is tied to a session which handles its state (new, dirty etc.). SA 0.2 > allows the user to handle session explicitly, but the threadlocal mod > restores 0.1 behaviour - where there's basically an implicit > per-thread session. Thinking about this more properly now, I actually don't think it makes a big difference. TG can automatically get a session and hang on to it per request, or we can use the threadlocal. It'll wind up in a threadlocal somewhere. There's a certain appeal to having TG do it, since we would, theoretically, know where the session boundaries are (since we already do the same kind of thing with SQLObject transactions). 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 -~----------~----~----~----~------~----~------~--~---
