Subject | Transactions in a stateless environment |
---|---|
Author | Adam Clarke |
Post date | 2001-01-23T03:22:35Z |
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
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