Subject RE: [IB-Architect] Transactions in a stateless environment
Author Leyne, Sean

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


-----Original Message-----
From: Adam Clarke [mailto:Adam.Clarke@...]
Sent: Monday, January 22, 2001 10:23 PM
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
applications. 2 have used MySQL (I know - not my idea - never again
and one uses Interbase.

The Interbase based application is complex enough that it is there will
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

1. HTTP is stateless
2. Standard technologies used in web programming (Apache, CGI, PHP etc)
it very difficult to both keep database handles open, and synchronise
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
(on a seperate HTTP session) b) UPDATEs the data, it is useless trying
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
browser. This session identifier is a primary key to a table which
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
Persistent Connection from within Interbase. This would return a unique
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
some timeout param which allowed failed / dead / unwanted connections to
cleaned away.

I guess that this turns the standard connection model on it's head (or
least on it's side) so it may be technically problematic. It might also
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
is what I have described it seems overkill - just another layer to
understand and convince some sys-admin to install.

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

Thanks for reading this far!

Adam Clarke
Strategic Data Pty Ltd

Ph : +61 (3) 9348-2013
Fax: +61 (3) 9348-2015
Mob: 0419 304-590
Email: Adam.Clarke@...
Post: P.O. Box 4262
Melbourne University, VIC 3052

To unsubscribe from this group, send an email to: