Hello everyone,
Lately I've been wondering about a new framework for AOLserver web
applications. Term "package" below is used to describe on-demand loaded
Tcl code, where one package usually serves one application, where usually
one application resides per one domain. The previous model is currently
used in production on servers that handle many (about 100) domains and
about the same number of packages and web applications.
Previously (with 3.4) I've been using the following:
1/ code that allowed dynamic loading of "packages";
The code that was contained in it's own namespace and was loaded/unloaded
on demand with reloading on changes.
2/ nsdqe provided session handling - setting the cookie and using ns_set
for data plus serialization to harddrive
This was handling all the session stuff plus logging in/logging out.
3/ nscache and similar code to handle cache'ing
This seems to work ok, but for generic approach what I really lack is an
OO - ie so that someone could develop a generic "ecommerce" class and
inherit for specific implementations. This can be done writing plain procs
and passing proper args/configuration variables, but I find this task a
job for actual OO.
This also has a downside that ns_cache cannot actually cache Tcl_Obj so if
I would get a result from the db this would get serialized to a string and
deserialized on first use. I did develop some cache mechanism that does
"deepcopy" of the objects and then caches the Tcl_Obj themselves for each
thread, this improved the speed a lot.
Right now I'm wondering the pros and cons of the following solution (using
4.0.10, 8.4.12, thread 2.6.3 and some other extensions).
1/ similar code, but one that would initialize a separate thread for each
package and load all the neccessary code in there - the package code would
be Itcl classes and plain Tcl code
(in the future this could use VFS and maybe tbcload to allow
redistribution of the code)
2/ session mechanism (which would require sessions to initialize main
website engine) that would create instance of an application object per
each session - so that each user would be an instance
3/ most data would be cached using Tcl_Objs (maybe even not using nscache)
4/ Background jobs could also use the same thread, using common
non-AOLserver methods (after/fileevent etc)
The objects would allow serialization/deserialization by supplying
name-value data that would be saved by the session manager. Session would
only allow X number of concurrent sessions and serialize+delete the oldest
ones when new ones need to be created.
Pros:
* much better app designing framework
* using event loop for packages
* one thread per package would solve most multi user scenarios
Cons:
* any change in the package code would require serializing all instances
and reloading the package
(but it's not common to experiment with
* non-session aware browsers will not be able to use most of the
functionality
(some functionality could be done by supplying a generic instance for
all non-session aware)
* it would be easy to do a DoS by generating a lot of sessions
(since serialization/deserialization would take a lot of time)
* sync DB operations could cause a freeze for many customers (especially
with long lasting queries)
Any comments on this?
--
Wojciech Kocjan
[EMAIL PROTECTED]
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
