[postgis] Next Level Redux

Paul Ramsey pramsey at refractions.net
Tue Aug 14 18:05:23 PDT 2001


Frank Warmerdam wrote:

> It would depend on your language of implementation.  Because so much is
> separated out into the database which has it's own concept a long running
> process for maintaining some state and caching I would hope a light cgi-bin
> impelementation would be fine.  Of course, I don't know too much about
> how Java stuff is done in a web environment.  You certainly don't want to
> start a JVM for each call.

Laugh if you will, but I was actually thinking about perl... one can
prototype with a CGI and go long-running with mod_perl when performance
is a problem. The thing about transactional stuff is that you run up
against one of the interesting and silly quirks that doing GIS
operations over HTTP gives you:

1-  Client to WFS: Lock feature X!
1-  WFS to Client: Locked.
2-  Client to WFS: Here's an update to feature X!
2-  WFS to Client: OK, thanks.

HTTP session 1 actually *ends* and session 2 is a completely new
connection. If you have a simple CGI, it will shut down and lose all its
state between connection 1 and 2. For database purposes, this means you
lose your connection to the database, and hence also your transaction,
*oof*! So for simple CGI, you have to do the locking *yourself*, fun!
However, with a long-running process, you can maintain your database
connection between HTTP requests, and therefore can delegate the
maintenance of the lock to the database. The trick then is matching up
clients to their locks: I have to go back to the spec, I am assuming a
lock request generates a lock key for the client.

> Well, there are a few WFS clients in existance now - including GeoMedia
> (or at
> least an upcoming GeoMedia) but you are right that there wouldn't be too
> much.

That's good news... I guess nothing from ESRI though :) 

-- 
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: pramsey at refractions.net
     | Phone: (250) 885-0632
     \_

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 





More information about the postgis-users mailing list