Has anyone had significant speed issues using the PyGreSQLDA? It seems like I'm only getting one DB connection at a time. Is this an issue with the DA, with Zope, or am I doing something wrong? I have a pgsql db running just fine, and in Zope I have a connection instantiated at the top level that all of my ZSQL methods use. Shouldn't it still be able to establish multiple connections, though? I guess I'm confused as to how it works. Thought I was using it right, but if I execute a query through Zope it takes a few milliseconds unhindered. However, if multiple people try to run a query at the same time, it usually takes a few seconds, as if only one person were connected at a time. I'd love elucidation from someone educated on this subject, as I am most certainly not :) ~ Dave
On Tue, 26 Sep 2000, Leichtman, David J wrote:
Has anyone had significant speed issues using the PyGreSQLDA? It seems like I'm only getting one DB connection at a time. Is this an issue with the DA, with Zope, or am I doing something wrong? I have a pgsql db running just
I have 3 connections just fine. Sometimes Zope timeouts a connection, but when someone touches it, Zope reopens the connection automatically. No problem thus far. Oleg. ---- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
"Leichtman, David J" wrote:
Has anyone had significant speed issues using the PyGreSQLDA? It seems like I'm only getting one DB connection at a time. Is this an issue with the DA, with Zope, or am I doing something wrong? I have a pgsql db running just fine, and in Zope I have a connection instantiated at the top level that all of my ZSQL methods use. Shouldn't it still be able to establish multiple connections, though? I guess I'm confused as to how it works. Thought I was using it right, but if I execute a query through Zope it takes a few milliseconds unhindered. However, if multiple people try to run a query at the same time, it usually takes a few seconds, as if only one person were connected at a time.
I'd love elucidation from someone educated on this subject, as I am most certainly not :)
ZPYGre is not threadsafe, so with it and all non-threadsafe da's zope uses a lock around access. (Thunked.py) The solution is to just use multiple DA connections and let postgres sort out the concurrency issues. Cheers Kapil
ZPYGre is not threadsafe, so with it and all non-threadsafe da's zope uses a lock around access. (Thunked.py)
The solution is to just use multiple DA connections and let postgres sort out the concurrency issues.
i'm not clear about "use multiple DA connections". let's say i have several sql methods. it is meant for one particular app. do i create a few db connections and assign them to different sql methods? anybody know whether PoPy is threadsafe already? thanks and sorry to be a bone head :)
Cheers
Kapil
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- http://www.kedai.com.my/kk http://www.kedai.com.my/eZine Get the tables!
"Bak @ kedai" wrote:
ZPYGre is not threadsafe, so with it and all non-threadsafe da's zope uses a lock around access. (Thunked.py)
The solution is to just use multiple DA connections and let postgres sort out the concurrency issues.
i'm not clear about "use multiple DA connections". let's say i have several sql methods. it is meant for one particular app. do i create a few db connections and assign them to different sql methods?
i would factor your sql methods into logical groups and give dedicated connections to groups which might have signifigant concurrent access. Giving dedicated connections to every method is not productive as you just increase concurrency problens on the db side. an example might be a dedicated connection for user related info, sessions, etc. and another for a news system.
anybody know whether PoPy is threadsafe already?
some reference regarding threadsafety as defined by the python dbi from the db-sig group. BEGIN REF Integer constant stating the level of thread safety the interface supports. Possible values are: 0 = Threads may not share the module. 1 = Threads may share the module, but not connections. 2 = Threads may share the module and connections. 3 = Threads may share the module, connections and cursors. Sharing in the above context means that two threads may use a resource without wrapping it using a mutex semaphore to implement resource locking. Note that you cannot always make external resources thread safe by managing access using a mutex: the resource may rely on global variables or other external sources that are beyond your control. END REF First this is in regards to the underlying python lib that drives the DA. both PyGre and PoPy are thread safety 1. Words have been said to the effect that the developers of PoPy would like to raise the thread safety of PoPy to 2. I'm not sure if D'arcy(author PyGre) has any such plans, however he is a contributor to Postgres and does maintain PyGre. PyGre did not use to conform to the python DBI, since it was written to support the features of Postgres, there is a now a wrapper around it provide this abstraction. PoPy was built to support the python DBI. I bring this info up because the DA for PyGre is dated and does not appear to be supported, but its important to realize that this DA is just a thin wrapper around the underlying db access lib, and for Postgres both of these are being worked on. if you really want a thread safe DA you're going to have to look towards the commercial DBs. rumor has it that someone at DC is writing a new Oracle adaptor.
thanks and sorry to be a bone head :)
no worries, if people never asked than we would all be learning by trial and error.
Cheers
Kapil
participants (4)
-
Bak ＠ kedai -
Kapil Thangavelu -
Leichtman, David J -
Oleg Broytmann