Webware for Python

I had some similar issues,

A python module runs the first time its called and then stays resident in the python interpreter for the duration of the app.
So anywhere you have a module you can define a new global variable.

Here is a snip of my configuration.py file that gets imported by each servlet

datapool = DBPool(PgSQL, 1, '192.168.0.10::comsci:user:pass')
clientpool={}
clientpool['metrony']=DBPool(PgSQL, 2, '192.168.0.10::metrony:user:pass')

And then to use any connection I call it like:

from configuration import datapool,clientpool

#
#  This is a big ugly class to handle all of the database interaction.
# It will get better

def summaryStats(user):
  summary={}
  conn=clientpool[user.company].getConnection()
  c=conn.cursor()
  c.execute("Select numrows from numrows")
  r=c.fetchone()
  summary['numrows'] = r.numrows
  return summary

So I create a dictionary of DB connections and use the company name as the key.

Now if I could only close the connections cleanly.......

-Aaron

----- Original Message ----- 
From: "Aleksandar Kacanski" <kacanski@...>
To: <webware-discuss@...>
Sent: Monday, November 12, 2001 11:57 AM
Subject: [Webware-discuss] approach to db connection pooling


> Any new developments on the db connection
> pooling?
> I have been trying for couple of days
> (unsuccessfully) to make some sort of 
> session caching, attaching db object to the
> Application object or Cans approach.
> Does anyone has any examples of how this might be
> implemented. I am interested in getting several
> connections open at the startup of the App, and
> passing the object to servlets.
> any suggestions?
> 
> __________________________________________________
> Do You Yahoo!?
> Find a job, post your resume.
> http://careers.yahoo.com
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss

On Monday 12 November 2001 11:15 am, Aaron Held wrote:
> Now if I could only close the connections cleanly.......

Have you tried atexit?
   http://www.python.org/doc/current/lib/module-atexit.html

Also, does anything bad actually happen if the connection gets dropped? I would think such a database server would be too unstable for real use...

-Chuck

I read article (Message: 4217027) and implemented
what Jay Love suggested.
This was something down the line of implementing 
Application.__init__() that sets up initial
connection method, and servlets accessing it via
Application object through self.application() and
 awake() method.
My connection to the DB is cached. In servlets I
use awake() and do something like this:
self.c = self.application().MyDBConn to get the
pyPgSQL connection  object.

I have wrapper that manipulates stuff on pyPgSQL
level that is used in both connection and
manipulation of the data.

I think that as is I am passing object from the
servlet to servlet.

I am still not sure on how to implement a proper
closure of the DB connection, dough i have it
implemented in the wrapper. I guess that  atexit
as Chuck suggested could be implemented.
I am not sure how above approach affects multi
threading.
Maybe someone could shed some light on this one?
thanks for the response. I'll try your approach.



--- Aaron Held <aaron@...> wrote:
> I had some similar issues,
> 
> A python module runs the first time its called
> and then stays resident in the python
> interpreter for the duration of the app.
> So anywhere you have a module you can define a
> new global variable.
> 
> Here is a snip of my configuration.py file that
> gets imported by each servlet
> 
> datapool = DBPool(PgSQL, 1,
> '192.168.0.10::comsci:user:pass')
> clientpool={}
> clientpool['metrony']=DBPool(PgSQL, 2,
> '192.168.0.10::metrony:user:pass')
> 
> And then to use any connection I call it like:
> 
> from configuration import datapool,clientpool
> 
> #
> #  This is a big ugly class to handle all of
> the database interaction.
> # It will get better
> 
> def summaryStats(user):
>   summary={}
>   conn=clientpool[user.company].getConnection()
>   c=conn.cursor()
>   c.execute("Select numrows from numrows")
>   r=c.fetchone()
>   summary['numrows'] = r.numrows
>   return summary
> 
> So I create a dictionary of DB connections and
> use the company name as the key.
> 
> Now if I could only close the connections
> cleanly.......
> 
> -Aaron
> 
> ----- Original Message ----- 
> From: "Aleksandar Kacanski"
> <kacanski@...>
> To: <webware-discuss@...>
> Sent: Monday, November 12, 2001 11:57 AM
> Subject: [Webware-discuss] approach to db
> connection pooling
> 
> 
> > Any new developments on the db connection
> > pooling?
> > I have been trying for couple of days
> > (unsuccessfully) to make some sort of 
> > session caching, attaching db object to the
> > Application object or Cans approach.
> > Does anyone has any examples of how this
> might be
> > implemented. I am interested in getting
> several
> > connections open at the startup of the App,
> and
> > passing the object to servlets.
> > any suggestions?
> > 
> >
>
__________________________________________________
> > Do You Yahoo!?
> > Find a job, post your resume.
> > http://careers.yahoo.com
> > 
> >
> _______________________________________________
> > Webware-discuss mailing list
> > Webware-discuss@...
> >
>
https://lists.sourceforge.net/lists/listinfo/webware-discuss
> 
> 

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

On Mon, Nov 12, 2001 at 09:16:51AM -0500, Geoff Talvola wrote:
> At 04:27 PM 11/11/01 +0100, Philipp Siegert wrote:
> >In the 0.6b2
> >release there is support for handling sessions without cookies at the costs
> >of uglier URLs. In PHP4 these ugly URLs are only used if the browser 
> >doesn't
> >support cookies. Is it possible to implement an intelligent mechanism in
> >webware which only uses ugly URLs if cookies are disabled? > 

> How do you detect if the browser has cookies enabled?

The PHPLib way seems to be that it always sends the session ID with the
URL at the first request, while also sending a cookie.  Then at
subsequent requests, it checks whether the cookie was received.  If yes,
it doesn't need the URL session ID so it stops sending it.  If no, it
continues sending the session ID in the URL.

Somehow it also manages to recover when cookies are turned off in the
middle of the session.  I'm not sure how.

The session management built into PHP 4 is a different beast; I'm not
sure what it does.

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

On Monday 12 November 2001 07:57 am, Mike Orr wrote:
> The PHPLib way seems to be that it always sends the session ID with the
> URL at the first request, while also sending a cookie.  Then at
> subsequent requests, it checks whether the cookie was received.  If yes,
> it doesn't need the URL session ID so it stops sending it.  If no, it
> continues sending the session ID in the URL.

That's the standard trick and the only one I'm actually aware of.


> Somehow it also manages to recover when cookies are turned off in the
> middle of the session.  I'm not sure how.

I don't believe you.  :-)

Except for form submission. It could embed the id in each form which could mitigate the problem, but not solve it.


> The session management built into PHP 4 is a different beast; I'm not
> sure what it does.

I think it has to set the cookie and then check for it in subsequent requests. But if there is another technique, I'd certainly like to hear about it.


-Chuck

On Mon, 2001-11-12 at 13:56, Chuck Esterbrook wrote:
> On Monday 12 November 2001 07:57 am, Mike Orr wrote:
> > The PHPLib way seems to be that it always sends the session ID with the
> > URL at the first request, while also sending a cookie.  Then at
> > subsequent requests, it checks whether the cookie was received.  If yes,
> > it doesn't need the URL session ID so it stops sending it.  If no, it
> > continues sending the session ID in the URL.
> 
> That's the standard trick and the only one I'm actually aware of.

There might be something with web bugs.  I figure such a bug is one of
the few (good) ways of really telling if the user has Javascript
enabled.  Maybe it can do double duty with cookies too?  Maybe if
someone doesn't have a session set, send them their new session ID, and
something like:

<script language="JavaScript"><!--
document.write('<img src="/JavascriptBug?SID=%s&JS=yes" height=0
width=0>');
//--></script>
<noscript><img src="/JavascriptBug?SID=%s&JS=no" height=0
width=0></noscript>

The first page will still have to have SIDs in all the links, and every
page will have to have support for setting this up, so I don't know if
this provides any benefit, or is even substantially different.

> > Somehow it also manages to recover when cookies are turned off in the
> > middle of the session.  I'm not sure how.
> 
> I don't believe you.  :-)
> 
> Except for form submission. It could embed the id in each form which could mitigate the problem, but not solve it.

Well, maybe the way it works is:

If you get a request that includes no SID, immediately redirect the user
to the page + SID.  Also set the SID cookie (but there's a bug in IE
regarding cookies and redirects, isn't there?  Or is it just an
Apache/IE conflict that might be resolvable?)

That won't exactly recover the session, though.  Anyway, if you are
willing to pay a two-redirect penalty for the first page view, you could
get a concrete answer.  I.e., user requests /startpage, redirect
/detect/startpage?SID=xxxx, if you don't get a cookie redirect to
/SID=xxxx/startpage, else redirect right back to /startpage.  This
wouldn't require any HREF munging, but would leave clean URLs when
possible.  If you only use relative URLs, which I find difficult.

  Ian

On Mon, Nov 12, 2001 at 11:56:08AM -0800, Chuck Esterbrook wrote:
> > Somehow it also manages to recover when cookies are turned off in the
> > middle of the session. ?I'm not sure how.
> 
> I don't believe you.  :-)

You're right, it does create a new session at that point.  I just never 
looked at the session ID closely.

The source for PHPLib's session handling is at http://phplib.netuse.de/ ,
download phplib-7.2d or the latest, look in php/session.inc .  I started
an analysis of it, but I'm more interested in Cheetah's future $batch
function at this point.

BTW, please try not to hardwire Javascript into Webware unless it's really
unavoidable.  

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

> There might be something with web bugs.  I figure such a bug is one of
> the few (good) ways of really telling if the user has Javascript
> enabled.  Maybe it can do double duty with cookies too?  Maybe if
> someone doesn't have a session set, send them their new session ID, and
> something like:
>
> <script language="JavaScript"><!--
> document.write('<img src="/JavascriptBug?SID=%s&JS=yes" height=0
> width=0>');
> //--></script>
> <noscript><img src="/JavascriptBug?SID=%s&JS=no" height=0
> width=0></noscript>

I don't think that Javascript is a good idea to solve this problem. Most 
people I know disable cookies for privacy reasons. They often disable 
Javascript for security reasons, too. There are even some computer magazines 
which advise their users to disable both techniques. The main reason to use 
an intelligent session management is IMHO to give nearly ALL users the 
ability to use a webware based system.

Philipp

-- 
Philipp Siegert
siegert@...
http://www.pp-services.de