Subject | Re: [IB-Architect] Transactions in a stateless environment |
---|---|
Author | Jason Wharton |
Post date | 2001-01-23T04:59:27Z |
Adam,
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.
In fact, I am aware of various products that have a model similar to this.
Take ASTA for example. It has various modes of session pooling. In some
cases it isn't required that a client have a persistent session and so it is
possible to grab any number of the available ones from the pool. For other
applications it is possible to tell it to make one client have a dedicated
session on the server-side. Obviously there are tradeoffs in doing this.
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. Each web-page
should have a session id so that between each page request it will be able
to validate the flow of the users posts and provide validation, etc. Each
webhit should result in a completed transcation (or series of). The session
data being kept should eventually be timed out and removed.
I suppose to continue on much more would be beyond the scope of this forum.
Perhaps you could suggest how a generic interface could be architected to
provide these services in a general way. I know that the
InterServer/InterClient combo are a similar step in that direction except
that it doesn't do any session pooling or seem to provide any load balancing
to allow many clients to be serviced by just a small pool of actual database
connections.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
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.
In fact, I am aware of various products that have a model similar to this.
Take ASTA for example. It has various modes of session pooling. In some
cases it isn't required that a client have a persistent session and so it is
possible to grab any number of the available ones from the pool. For other
applications it is possible to tell it to make one client have a dedicated
session on the server-side. Obviously there are tradeoffs in doing this.
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. Each web-page
should have a session id so that between each page request it will be able
to validate the flow of the users posts and provide validation, etc. Each
webhit should result in a completed transcation (or series of). The session
data being kept should eventually be timed out and removed.
I suppose to continue on much more would be beyond the scope of this forum.
Perhaps you could suggest how a generic interface could be architected to
provide these services in a general way. I know that the
InterServer/InterClient combo are a similar step in that direction except
that it doesn't do any session pooling or seem to provide any load balancing
to allow many clients to be serviced by just a small pool of actual database
connections.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com