Scavenging the mail folder uncovered Paolo Comitini's letter:
what's the current status of ZPygreSQLDA and ZPoPyDA? if i were to choose, which should i use? and the reasons for using it?
i understand that ZPoPyDA is level 2 thread safety, and not quite sure what ZPygreSQLDA thread safety is.
I can only say that we started writing PoPy and ZPoPyDA because pygresql (and the adapter based on it) are *not* thread safe. we were experimenting deadlocks in zope when you mix db access from sql methods and external methods in the same page. on the other hand PoPy is pretty new and, before using it in production, needs more testing. i think it will stabilize pretty soon, because we will use it to build the web sites for our customers really soon now and that will apport a lot of testing/debugging. make your choice and be happy, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The reverse side also has a reverse side. -- Japanese proverb
I can only say that we started writing PoPy and ZPoPyDA because pygresql (and the adapter based on it) are *not* thread safe. we were experimenting deadlocks in zope when you mix db access from sql methods and external methods in the same page.
quoting DAroadmap at http://www.zope.org/Members/petrilli/DARoadmap """ Level 2 Level 2 database adapters must be safe to use in a multi-threaded Zope instance. This can take multiple behaviour paterns: Internal locking/mutexes for single DA access Global locking through the transaction manager if appropriate While a sub-optimal solution, it should be usable on any application that has minimal, or infrequent, database access. This means that all access paterns will be serialized. In addition, all DAs at this level must release the Python global interpreter lock. """ i assume ZPoPyDA conform to the above statement. will you make ZPoPyDa into level 3 anytime soon?
on the other hand PoPy is pretty new and, before using it in production, needs more testing. i think it will stabilize pretty soon, because we will use it to build the web sites for our customers really soon now and that will apport a lot of testing/debugging.
i will try ZPoPyDA on my personal site, and will inform you of any misbehaviour. BTW, what symptoms should i look out for if ZPoPyDa misbehave? Zope locking/not responding?
make your choice and be happy, made mine already, thanks, and
""" I'll be back! """
federico
-- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The reverse side also has a reverse side. -- Japanese proverb --
http://www.kedai.com.my/kk Am I Evil?
Someone please correct me if I have gotten the stuff below wrong. ------------------- If I read the stuff on the PoPy web site correctly, it is a Level 2 Database Adapter that is level 1 thread safe. The level 1 refers to level of thread safety not database adapter level. Level 1 thread safety means that multiple threads can share the module but each thread must have its own database connection. Level 2 thread safety means that multiple threads can share the module and connections. Level 3 thread safety means that multiple threads can share the module and connections and cursors. ----- Original Message ----- From: "Bak @ kedai" <kedai@kedai.com.my> To: "Federico Di Gregorio" <fog@mixadlive.com> Cc: <zope@zope.org> Sent: Friday, June 02, 2000 4:10 AM Subject: [Zope] Re: Fwd: [Zope] postgres DA
I can only say that we started writing PoPy and ZPoPyDA because pygresql (and the adapter based on it) are *not* thread safe. we were experimenting deadlocks in zope when you mix db access from sql methods and external methods in the same page.
quoting DAroadmap at http://www.zope.org/Members/petrilli/DARoadmap """ Level 2 Level 2 database adapters must be safe to use in a multi-threaded Zope instance. This can take multiple behaviour paterns: Internal locking/mutexes for single DA access Global locking through the transaction manager if appropriate While a sub-optimal solution, it should be usable on any application that has minimal, or infrequent, database access. This means that all access paterns will be serialized. In addition, all DAs at this level must release the Python global interpreter lock. """ i assume ZPoPyDA conform to the above statement. will you make ZPoPyDa into level 3 anytime soon?
on the other hand PoPy is pretty new and, before using it in production, needs more testing. i think it will stabilize pretty soon, because we will use it to build the web sites for our customers really soon now and that will apport a lot of testing/debugging.
i will try ZPoPyDA on my personal site, and will inform you of any misbehaviour. BTW, what symptoms should i look out for if ZPoPyDa misbehave? Zope locking/not responding?
make your choice and be happy, made mine already, thanks, and
""" I'll be back! """
federico
-- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The reverse side also has a reverse side. -- Japanese proverb --
http://www.kedai.com.my/kk Am I Evil? _______________________________________________ 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 )
participants (3)
-
Bak ＠ kedai -
fog＠mixadlive.com -
Jim Sanford