You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl> on 2001/06/11 20:38:41 UTC
Re: Next Big Apache::ASP Feature?
> * $Session & $Application stored in the database. In case
> Apache::Session is not good enough, this would store
> state in databases, and also enable things like Session
> garbage collection & events like Session_OnEnd.
This feature has my vote.
I could/would also like to work on this.
--
Dariusz Pietrzak
Certified Nobody
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Next Big Apache::ASP Feature?
Posted by Joshua Chamas <jo...@chamas.com>.
Dariusz Pietrzak wrote:
>
> > create table asp_state (
> > group_id varchar(12) NOT NULL,
> > state_id varchar(32) NOT NULL,
> > subkey varchar(200) NOT NULL,
> > deletion datetime NULL,
> > data text/long,
> > primary key(group_id, state_id, subkey)
> > )
> what is group_id ? (sorry haven't dug current sessions implementation yet,
> I'll get to it ASAP )
>
Mostly for file system compatibility, a group_id of "server"
is where state ids application & internal would be stored.
I could probably get away with not doing this, but it
might be a very nice way of differentiating state in the
db without having to worry about naming conventions.
> varchar indexing is rather slow under many SQL servers/version, maybe
> there could be something faster?
What kind of performance difference on what SQL server ...
are we talking inserts? Updates won't happen. Do you have
benchmarks? I have always thought that varchar vs. char
differences to be in the 10% range in performance which
I'm not worried about, but if its 1/2 the speed, then
this is worth designing around.
> (as I understend there would be a lot of search on group_id, state_id and
> subkey )
Yes, there will be lots of selects, so a benchmark
here would be relevant, char vs. varchar.
>
> > However $Session will be default likely behave like
> > an Apache::Session, with all the data being read
> > at the beginning of the request, and written out
> is this really neccesery?
>
No, in fact I may not do it for complexity reasons.
The reason Apache::Session does it is for speed ...
if all you have is a couple subkeys to read like:
$Session->{Key1} && $Session->{Key2}
Then it will be faster to have just read the data
once at $Session init and lock the session for
serialization, than to read two subkeys separately.
> I have no idea. Why not adopt what Apache::AuthDBI does?
> Although that way there would be no way to re-use that connection.
> Hmm, but re-using that connection would mean that apache session would
> use applications database and pollute it with it's tables.
> I think sessions should be more transparent and less invasive by default.
If a developer needs to set up the connection, then they
can set it up to where they want. Generally, once someone
has a schema setup in Oracle or database in mysql, they'll
just reuse that for their session storage for convenience,
otherwise you'd have to have a special naming convention
to access the table like other_db.asp_state in mysql, or
setup another connection to the db with its own "use database".
Generally, multiple connections to databases in mod_perl
is not a good thing, because they each take XM RAM. Oracle
connections generally start out at 3M RAM at least, and MySQL
1M RAM, and if you are running 50 httpds, that could quickly
eat up a large chunk of RAM. So 50M for each extra MySQL
database connection that you want to keep persistent with
Apache::DBI.
The problem with a setup like this:
PerlSetVar Auth_DBI_data_source dbi:driver:dsn
PerlSetVar Auth_DBI_username db_username
PerlSetVar Auth_DBI_password db_password
is that Apache::DBI will cache database connections
based on extra connect params like RaiseError & AutoCommit,
so you have to match up everything to get the same
cached DBH. Better to just use your application's
DBI->connect() method for guaranteed reuse.
The most elegant solution I have see so far to this
is in Apache::Session where you can pass the handle
to the tied %session:
tie %hash, 'Apache::Session::Oracle', $id, {
Handle => $dbh,
Commit => 1
};
But Apache::ASP doesn't need a developer to tie anything, just
get them a dbh.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: global.asa, applications and subdirectories
Posted by Joshua Chamas <jo...@chamas.com>.
"John D. Leonard II" wrote:
>
> All:
>
> How are multiple copies of .htaccess and global.asa handled? My question
> relates to the use of FrontPage and Apache::ASP. (This is how I craft
> pages, whether under IIS/ASP or Apache::ASP.
>
> FYI - FrontPage creates "new webs" under the DocumentRoot. I would like
> each of these subdirectories to have their own .htaccess, global.asa,
> $Session and $Application spaces. No problem, expect my document root also
> has it's own .htaccess and global.asa files.
>
.htaccess configs may be cumulative. You should experiment and see.
global.asa's definately are not. Only the Global directory is checked
which defaults to the current directory the ASP script is in.
> What settings must I change to ensure that various "subwebs" (and their
> global variables) don't conflict with each other, and the main web off
> document root?
Separate .htaccess file's won't conflict in directories at the
same level as each other. Don't set GlobalPackage to the same thing.
Also, if you want to create common templates shared across
all your sites, you can use IncludesDir
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
global.asa, applications and subdirectories
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
All:
How are multiple copies of .htaccess and global.asa handled? My question
relates to the use of FrontPage and Apache::ASP. (This is how I craft
pages, whether under IIS/ASP or Apache::ASP.
FYI - FrontPage creates "new webs" under the DocumentRoot. I would like
each of these subdirectories to have their own .htaccess, global.asa,
$Session and $Application spaces. No problem, expect my document root also
has it's own .htaccess and global.asa files.
How are conflicts between parent and subdirectories handled? Which
global.asa takes precedence? I believe that IIS keeps them separate.
What settings must I change to ensure that various "subwebs" (and their
global variables) don't conflict with each other, and the main web off
document root?
Thanks!
JL
------
John D. Leonard II, Associate Professor Phone: 404/894-2360
School of Civil and Environmental Engineering FAX: 404/894-2278
Georgia Institute of Technology http://traffic.ce.gatech.edu
Atlanta, GA 30332-0355 mailto:john.leonard@ce.gatech.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Application object and DB handle
Posted by Joshua Chamas <jo...@chamas.com>.
"John D. Leonard II" wrote:
>
> All:
>
> I use DBI and PostgresSQL on Apache 1.3.20, mod_perl 1.25, and Apache::ASP
> 2.17.
>
> What is the "best" way to create and dispose of DB handles? Are there
> implementation or performance gotcha's between the following alternatives:
>
> A) Should I create and destroy a single global variable (e.g., $dbh) in the
> Application_OnStart and _OnEnd.
>
No, the Application events do not reflect the state of the current
web httpd process executing. Each httpd needs its own connection
to the database, which consist of local RAM data structures and
file handles, network sockets, etc. that cannot be capture by
serialization into $Application or $Session.
For this reason the best place to do your db init is in Script_OnStart
like so:
# httpd.conf, always set UseStrict while developing...
# like "use strict" in perl
PerlSetVar UseStrict 1
# global.asa
use vars qw($Db); # declare global for use in scripts/includes
use Apache::DBI; # use before DBI
sub Script_OnStart {
$Db = DBI->connect(..., { RaiseError => 1 }); # always have RaiseError turned on
}
> B) Should each $Session create and destroy it's own DB handle stored in the
> $Session object?
>
No see above.
> C) Should each script create and destroy it's own handle in the
> Script_OnStart and _OnEnd?
>
Yes, see above.
> D) Should I use the approach offered by Apache::DBI?
>
Yes, see above.
The apache httpd web process model doesn't let you do some of the
neat things you can do under IIS because under IIS everything
runs under the web process, and under apache, each client
connection is handled by a separate forked child web process.
Even though this can cause some developer inconvenience,
this model greatly increases the stability of the web server,
because you can mess up your current web process in apache,
with some bad code without taking down the entire web server.
Things will change in the Apache 2.0 / mod_perl 2.0 however,
as one will be able to mix multiprocess models with threaded
model, so hopefully soon we will have the best of both worlds.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Application object and DB handle
Posted by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl>.
> What is the "best" way to create and dispose of DB handles? Are there
> Application_OnStart and _OnEnd.
I believe that would be the most efficient way.
> D) Should I use the approach offered by Apache::DBI?
and that would be the "best".
--
Dariusz Pietrzak
Certified Nobody
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Application object and DB handle
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
All:
I use DBI and PostgresSQL on Apache 1.3.20, mod_perl 1.25, and Apache::ASP
2.17.
What is the "best" way to create and dispose of DB handles? Are there
implementation or performance gotcha's between the following alternatives:
A) Should I create and destroy a single global variable (e.g., $dbh) in the
Application_OnStart and _OnEnd.
B) Should each $Session create and destroy it's own DB handle stored in the
$Session object?
C) Should each script create and destroy it's own handle in the
Script_OnStart and _OnEnd?
D) Should I use the approach offered by Apache::DBI?
Thanks!
JL
------
John D. Leonard II, Associate Professor Phone: 404/894-2360
School of Civil and Environmental Engineering FAX: 404/894-2278
Georgia Institute of Technology http://traffic.ce.gatech.edu
Atlanta, GA 30332-0355 mailto:john.leonard@ce.gatech.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Next Big Apache::ASP Feature?
Posted by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl>.
> create table asp_state (
> group_id varchar(12) NOT NULL,
> state_id varchar(32) NOT NULL,
> subkey varchar(200) NOT NULL,
> deletion datetime NULL,
> data text/long,
> primary key(group_id, state_id, subkey)
> )
what is group_id ? (sorry haven't dug current sessions implementation yet,
I'll get to it ASAP )
varchar indexing is rather slow under many SQL servers/version, maybe
there could be something faster?
(as I understend there would be a lot of search on group_id, state_id and
subkey )
> However $Session will be default likely behave like
> an Apache::Session, with all the data being read
> at the beginning of the request, and written out
is this really neccesery?
> code complexity. If someone wanted the flat model,
> and it wasn't built into Apache::ASP, then they
> could just use Apache::Session.
What are the advantages of flat model?
I think I don't fully understand it.
> Also, where to get the database connection?
oh. tricky.
I have no idea. Why not adopt what Apache::AuthDBI does?
Although that way there would be no way to re-use that connection.
Hmm, but re-using that connection would mean that apache session would
use applications database and pollute it with it's tables.
I think sessions should be more transparent and less invasive by default.
--
Dariusz Pietrzak
Certified Nobody
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Apropos sessions
Posted by Joshua Chamas <jo...@chamas.com>.
Dariusz Pietrzak wrote:
>
> Anyone tried using ramdisk as a placeholder for ASP session data?
> Judging by the amount of disk activity caused by hitting reload button on
> ASP page this would speed things up quite noticably.
> I am now running such configuration on 'production' machine and waiting
> for angry users to show up.
>
Yes, /tmp/ on Solaris x86 is a RAM disk, and that's where
I put my StateDirs
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Apropos sessions
Posted by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl>.
Anyone tried using ramdisk as a placeholder for ASP session data?
Judging by the amount of disk activity caused by hitting reload button on
ASP page this would speed things up quite noticably.
I am now running such configuration on 'production' machine and waiting
for angry users to show up.
--
Dariusz Pietrzak
Certified Nobody
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Next Big Apache::ASP Feature?
Posted by Joshua Chamas <jo...@chamas.com>.
Dariusz Pietrzak wrote:
>
> > * $Session & $Application stored in the database. In case
> > Apache::Session is not good enough, this would store
> > state in databases, and also enable things like Session
> > garbage collection & events like Session_OnEnd.
> This feature has my vote.
I think you win... better to add power to the hands of the
developers already working with Apache::ASP, than try
to entice VBScript users to the platform for now.
Database $Session & $Application support has been a
long requested feature.
> I could/would also like to work on this.
>
Depending on how much time I have free in the next
few weeks, I may take you up on this. I might
just knock it out myself though.
What I'm thinking is something similar to Apache::Session,
but slightly different. First of all, creation/updation/deletion
dates will be important and might find themselves as part
of the schema def for the state table, something like:
create table asp_state (
group_id varchar(12) NOT NULL,
state_id varchar(32) NOT NULL,
subkey varchar(200) NOT NULL,
deletion datetime NULL,
data text/long,
primary key(group_id, state_id, subkey)
)
This will allow for a similar mapping that already
exists for the directory/DBM based implementation.
The trick here is that while $Application and $Internal
(used internally for session management) will
have "subkeys" by default, $Session will not. Having
subkeys in the table will make is so that
$Application->{Key1}
$Application->{Key2)
would each invoke SQL to read in the data from
the DB like
select data from asp_state
where group_id = 'server'
and state_id = 'application'
and subkey = 'Key1'
allowing for larger objects to be stored in $Application
on a per key basis without having to read all the keys
like Apache::Session.
However $Session will be default likely behave like
an Apache::Session, with all the data being read
at the beginning of the request, and written out
at the end if anything is different. This data might
be stored in some default subkey like "DATA", with SQL
like:
select data from asp_state
where group_id = '12'
and state_id = '1234123123432141234'
and subkey = 'DATA'
This could only work though if SessionSerialize were
the default for these types of sessions. If someone
wanted to stored larger objects in session but didn't
want to necessarily access all of them during
the request, they might pick the deep subkey
$Application model.
I know that I need a deep subkey model. I don't
know that doing both models is a good idea for
code complexity. If someone wanted the flat model,
and it wasn't built into Apache::ASP, then they
could just use Apache::Session.
Also, where to get the database connection?
I imagine, that in global.asa, one would define:
# global.asa
sub Script_OnDBIConnect {
DBI->connect(...) or
My::DB->init(...)
}
This then could easily reuse your database connection
that your Application uses, especially where Apache::DBI
might be caching the connection.
Initial platform support would include Oracle & MySQL
as these are platforms with which I am familiar.
Hopefully the implementation will be flexible enough
to easily plug in additional databases.
Any feedback would be great.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks <- Web Link Checking Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org