----- Original Message -----
From: "Jason Wharton" <jwharton@...>
Sent: Tuesday, January 23, 2001 3:59 PM


> There is merit to your suggestions but I don't think these ideas belong in
a
> part of the InterBase server itself. I think there should be something
> external that provides the services you are requesting.

Why's that Jason? It would certainly make Interbase an appealing option if
you were trying to make an exisiting web based app more robust (coz it was
built on top of MySQL). I predict that this will be a major source of work
for web programmers in the next few years.

> With your web applications I would suggest that you use an ISAPI type
> interface so that you keep a pool of ready to execute statements, etc.
Then,
> in your database keep all of the state that is required.

I don't see that this allows me to do what I wanted, which is allow multiple
HTTP sessions interact with Interbase within the context of a single
transaction. Ideally this should be done in a way that does not require
complete re-architecting of the application (to ISAPI or the like which are
little used) but can be easily added to the vast majority of web
applications which are written in Perl (via CGI or mod_perl) or PHP
(sometimes via CGI) or Java (via servlets).

This situation has made me wonder if there a reason that transactions occur
within the context of a database connection other than the fact that
traditional client-server theory saw it that way. In the work that I do a
persistant net connection between client and server has nothing to do with
the logic of my application. Logically, if a client has requested to edit a
record then when I lose my connection (at the end of the HTTP stream) I'm
only half way through a transaction. Why should databases not support this
new model of client-server interaction?

Maybe there are good reasons, I'm asking because I don't know.

Cheers
Adam