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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
