just deal with the session, and bind it to an engine. saying
"engine.connect()" does nothing down there since you arent holding
onto anything. the engine itself is stateless with regards to
connections (unless you use the threadlocal strategywhich you
shouldnt).
On Apr 10, 2007, at
> the elegant way would be to not worry about the thread scope of a
> connection and just use connection pooling normally. pull out a
> connection when needed, close it when complete (which is really just
> a return to the connection pool). keep the scope of those two
> operations local
On Apr 9, 2007, at 11:54 AM, David Anderson wrote:
>
> On 4/9/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>>> I tried to build this already but I cannot figure out how to assign
>>> the shared connection to a thread. I always get 'No connection
>>> defined'.
>>
>> if youre on py2.4 check out th
On 4/9/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
> > I tried to build this already but I cannot figure out how to assign
> > the shared connection to a thread. I always get 'No connection
> > defined'.
>
> if youre on py2.4 check out threading.local().
Just to be clear here, as I'm also having
On Apr 9, 2007, at 5:18 AM, Koen Bok wrote:
>
> We are building a GUI app, and we were thinking about wrapping
> session.flush() in a thread with a timer that detects a timeout. That
> way we would have better performace and we can generate warnings if
> the connection goes down. Do you guys thi
may be a threadlocal strategy.
On 4/9/07, Koen Bok <[EMAIL PROTECTED]> wrote:
>
>
> We are building a GUI app, and we were thinking about wrapping
> session.flush() in a thread with a timer that detects a timeout. That
> way we would have better performace and we can generate warnings if
> the con
