[mod_python] ANNOUNCE: gila, mod_python util library

Up till now, I have always passed concurrency on to the database. If the 
session has made two concurrent requests altering the same data, then the 
state/value of the data is however the last request that commits the update 
left it. The data will be consistent, as the DB ensures consistent reads and 
writes as long as all work resides within a transaction. Counters also apply 
--- I just use a postgres sequence, or simulate one with mysql and tables. 
However, I am interested to see how you implemented this concurrancy.

In any case, I have always tried to use what was available, so most likely I 
will end up modifying my stuff to work atop the session support in 
mod_python.

On Tuesday 04 November 2003 11:05 pm, Gregory (Grisha) Trubetskoy wrote:
> On Tue, 4 Nov 2003, Michael Owens wrote:
> > That's a very interesting question, and frankly I've never given it a lot
> > of thought.
>
> I didn't give it a lot of thought either, until I came across the need for
> it. This turned out a bit more complex than orginally anticipated (ok,
> this is an understatement - it was a paint to get working), which is one
> of the main motivators for providing session support as part of mod_python
> (the latest beta has it).

> The notion of a session always (or almost always) assumes that no more
> than one request for a session is being processed at a time.  This is
> default behaviour in JSP, for example, even though the users often don't
> even know it.
>
> If you have a session that, say increments a counter, then unless you have
> some sort of a session locking mechanism, your numbers will increment, but
> not always as expected :-)


> Anyway - when I saw "session support" I thought there may be a chance you
> knew something I didn't :-)
>
> Grisha
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python