Subject Re: [IB-Architect] Transactions in a stateless environment
Author Adam Clarke

Thanks for your reply.

----- Original Message -----
From: "Leyne, Sean" <InterbaseArchitecture@...>
To: <>
Sent: Wednesday, January 24, 2001 1:29 AM
Subject: RE: [IB-Architect] Transactions in a stateless environment

> 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).

Currently (under Apache) the only way to implement what I described would be
to code an additional persistant server process which handled database
access on behalf of the non persistant "CGI type" processes.

It is this theoretical process that I referred to as the "middle tier",
perhaps I should have called it an "additional intermediate tier" since you
seem to consider the web server and/or any processes it may spawn to execute
scripts as a "middle tier". I suspect it is pretty much semantics in any

> 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.

However this is not trivial and adds another level of compexity to the
system. That's how it would need to be done now. My question is "Is that a
good thing, and if so why?".

I am happy to hear that the current way is for the best, and that I am mad
to suggest any other way of doing things. However a good answer as to why
this is the case is not, "Because that's how we do things".

(I'm reading this back and know that I may sound like I'm picking a fight -
I'm not, I'd just like to get to understand why Interbase is architected the
way it is, and if there is room for what I described to be supported in the

> Finally, some of the client information tracking functions as available
> without much coding through cookies and session variables.

Yep, use them all the time.

> 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.

Don't know or care about IIS. This is definitely not trivial on the most
popular UNIX web server however (Apache) although using Version 2.0 in a
fully threaded mode (when it's stable) may do the trick.