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. 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. If there is strictly one thread pr. request - threadlocal is probably they way to go. Of course the default session is reset (i.e. either flushed, saving all changes - or cleared, discarding changes) between requests. Arnar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
