BoundMetaData is what I am using.
On 7/20/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> and how is your session connected to the database ? are you using
> create_session(bind_to=) ? or are you binding your MetaData to
> the engine ? are you using BoundMetaData ?
> On Jul 19, 2007, at 11:16 PM,
"passing in the creator as a lambda: db_obj where db_obj is the ref
to method returning MySQldb connection."
...can we see the exact code for this please ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalch
and how is your session connected to the database ? are you using
create_session(bind_to=) ? or are you binding your
MetaData to the engine ? are you using BoundMetaData ?
On Jul 19, 2007, at 11:16 PM, Arun Kumar PG wrote:
> the stack trace points to pool.py (I will get the exact stack tra
the stack trace points to pool.py (I will get the exact stack trace as I am
away from my box currently)
>> does the conflict occur frequently and easily with just a little bit of
concurrency or is it
something that only happens under very high load conditions ?
this is happening primarily in a us
perhaps the nature of the conflict is different, then. are you able
to observe what stack traces or at least approximately what operations
are taking place when the conflict occurs ? does the conflict occur
frequently and easily with just a little bit of concurrency or is it
something that only
That is what I am trying to figure out. It works perfectly when I do this.
On 7/20/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jul 19, 2007, at 5:06 PM, Arun Kumar PG wrote:
>
> > or may be just keep on using the QueuePool approach as it will
> > always make sure to return the same con
On Jul 19, 2007, at 5:06 PM, Arun Kumar PG wrote:
> or may be just keep on using the QueuePool approach as it will
> always make sure to return the same connection to the current thread ?
>
like i said, i dont see how that helps any. a single Session thats
in flush() holds onto a single co
or may be just keep on using the QueuePool approach as it will always make
sure to return the same connection to the current thread ?
On 7/20/07, Arun Kumar PG <[EMAIL PROTECTED]> wrote:
>
> Or, you can create your mapped objects per request, yes, or perhaps
> per thread.
>
> >> how much can this
Or, you can create your mapped objects per request, yes, or perhaps
per thread.
>> how much can this cost in terms of performance ?
On 7/20/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jul 19, 2007, at 4:39 PM, Arun Kumar PG wrote:
>
> >
> > Will this be a problem even if I attach a ne
On Jul 19, 2007, at 4:39 PM, Arun Kumar PG wrote:
>
> Will this be a problem even if I attach a new session per incoming
> request i.e. thread handling request ? So basically it's because of
> having the same copy of mapped objects ? How can I solve the above
> problem in existing way with
On 7/20/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jul 19, 2007, at 2:08 PM, Arun Kumar PG wrote:
>
> > Apologies for not responding for a while Was stuck in the project.
> >
> > Ok. So this is what happening The mapped objects are created during
> > the first time request to the appli
On Jul 19, 2007, at 2:08 PM, Arun Kumar PG wrote:
> Apologies for not responding for a while Was stuck in the project.
>
> Ok. So this is what happening The mapped objects are created during
> the first time request to the application. So create_engine is
> getting called one time only passi
Apologies for not responding for a while Was stuck in the project.
Ok. So this is what happening The mapped objects are created during the
first time request to the application. So create_engine is getting called
one time only passing in the creator as a lambda: db_obj where db_obj is the
ref to m
On Jul 15, 2007, at 11:24 PM, Arun Kumar PG wrote:
> Hi Michael,
>
> I figured out the problem. It was a connection sharing issue. Looks
> like different connection objects were getting returned from the
> pool (which was created using the creator approach in create_engine
> ()) when relati
Hi Michael,
I figured out the problem. It was a connection sharing issue. Looks like
different connection objects were getting returned from the pool (which was
created using the creator approach in create_engine()) when relations were
getting loaded as a part of processing. Due to this sometimes
Sure Michael I will get back on this in a while as I am researching on this.
Thanks for your support. I hope this gets resolved sooner as I am very much
dependent on this and the application is really critical and should be up in
next couple days!
Thanks and i will get back on this in next couple
also send along a full stack trace so at least it can be seen where
this is occuring.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroup
On Jul 13, 2007, at 4:42 AM, Arun Kumar PG wrote:
>
> Any thoughts?
>
my thoughts are, either the bug still remains in SA's connection pool
and everyone is magically avoiding the problem somehow (when it was
fixed, people who observed the problem all the time noted that it
went away compl
Thx Michael.
Well, I don't think that I am doing that. To give you a picture of the
object model this is how the hierarchy is:
BaseOrmDao (+GetSession() this returns the
session attached to the current thread)
^
|
Request - >
On Jul 13, 2007, at 2:27 AM, Arun Kumar PG wrote:
> I create an orm session as soon as the request comes in and store
> the reference to the same in the curent thread i.e.
> threading.currentThread().session = new_session. This session is
> stored in the current thread so that I can get th
I create an orm session as soon as the request comes in and store the
reference to the same in the curent thread i.e.
threading.currentThread().session
= new_session. This session is stored in the current thread so that I can
get the same session across all DAO objects. so basically ever DAO in the
On Jul 13, 2007, at 1:47 AM, Arun Kumar PG wrote:
> Hi Guys,
>
> I am getting this error when multiple requests are coming to the
> application and following this the my server crashes!
>
> FYI:
> I am using MySQLDb library and connextions are managed by
> sqlalchemy.pool
>
> ProgrammingErro
22 matches
Mail list logo
