Adam,

How did you expect the web server to connect to the database?... via
web application logic or put another way an application server (i.e.
middle tier).

Accordingly, as Jason observed, the solution to this problem lies in the
implementation of this application logic/server.

With respect to your comment about an "additional layer" - it is a
necessary layer to support the functionality you've described.

Finally, some of the client information tracking functions as available
without much coding through cookies and session variables. In the case
of MS IIS you can persist any number of objects including complex
objects (i.e. OBDC database objects/connections) within a session
variable.


Sean

-----Original Message-----
From: Adam Clarke [mailto:Adam.Clarke@...]
Sent: Monday, January 22, 2001 10:23 PM
To: IB-Architect@egroups.com
Subject: [IB-Architect] Transactions in a stateless environment

Hi all.

Let me say up-front that I am no expert in this area, so feel free to
set me
straight if necessary, I can take it.

I have recently been involved in the production of three web hosted
database
applications. 2 have used MySQL (I know - not my idea - never again
etc.)
and one uses Interbase.

The Interbase based application is complex enough that it is there will
be
simultaneous updates to the same record(s) by different users. As a
consequence I started to think about how I could use Interbase's
transactions to manage this problem. I got stuck pretty quickly
because...

1. HTTP is stateless
2. Standard technologies used in web programming (Apache, CGI, PHP etc)
make
it very difficult to both keep database handles open, and synchronise
HTTP
sessions from the same client session with those handles.

Without the capacity to match up an active database handle on the server
with the server side processes which a) SELECT the data for editing and
then
(on a seperate HTTP session) b) UPDATEs the data, it is useless trying
to
use transactions.

Normally these problems of stateless connections are solved by passing a
session identifier around with the other data sent to/from the server
and
browser. This session identifier is a primary key to a table which
stores
persistant information such as username, etc. Unfortunately it is not
possible to store a database handle in a table, and in any case it is
probably a bad idea.

This got me thinking however. What if I was able to request an
Identified
Persistent Connection from within Interbase. This would return a unique
id
which I could use upon enstablishing a new database connection to tell
it to
import the state of that old connection. There would probably have to
be
some timeout param which allowed failed / dead / unwanted connections to
be
cleaned away.

I guess that this turns the standard connection model on it's head (or
at
least on it's side) so it may be technically problematic. It might also
be
undesireable for other reasons, that's why I posted, I'd like to hear.

I know that a middle tier could provide these services but if all you
need
is what I have described it seems overkill - just another layer to
maintain,
understand and convince some sys-admin to install.

My feeling is that currently some of the best features of a database
like
Interbase are wasted in web environments because of the stateless
problems.
The above suggestion would provide a simple way of accessing to these
features without re-engineering the standard method of building a web
app.

Thanks for reading this far!

Cheers
Adam Clarke
Principal
Strategic Data Pty Ltd

Ph : +61 (3) 9348-2013
Fax: +61 (3) 9348-2015
Mob: 0419 304-590
Email: Adam.Clarke@...
Web: http://www.StrategicData.com.au/
Post: P.O. Box 4262
Melbourne University, VIC 3052
Australia





To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com