On Tue, 1 Feb 2000, Pascal Eeftinck wrote:
> At 11:25 1-2-2000 -0600, Leslie Mikesell wrote:
> >According to Elizabeth Mattijsen:
> >
> > > We have been using such a setup for over 2 years now. The only real issue
> > > we've found is not so much with mod_perl itself, but with MySQL. If you
> > > put your databases on the NetApp, either have a seperate central database
> > > server, or make damn sure you do not use the same database from two
> > > different front-end servers. We've seen database corruption that way
> > > (using Linux front-end servers with NFS 2).
> >
> >It is probably reasonable for MySQL to assume that only one server
> >is accessing the files at once since it has its own remote client
> >access protocol. Do you happen to know if there is a performance
> >difference for MySQL between local drives and a NetApp?
>
> All MySQL operations are atomic. You can always be sure that no two threads
> will be updating a table at the same time, for example. If you need to work
> on multiple tables while making sure data stays consistent among them, lock
> these tables before use.
>
> A single MySQL server will have no problems running with its databases
> mounted on an NFS store, although performance probably won't be very good.
> It shouldn't hurt too much for huge tables that you don't access that
> heavily, but those that you do use frequently had better be kept on a local
> disk. Of course you can just make symlinks in your var directory to the
> tables that you've stored on an NFS store somewhere.
>
> Multiple MySQL servers running on the same database stored on an NFS store
> is not something you should try at all. Threaded locking is unreliable by
> itself on Solaris and Linux if I read the MySQL docs correctly, and NFS
> locking is worse than that. You'd absolutely need a thread-safe flock()
> implementation that works over NFS as well - good luck with your quest. :)
>
>
> When you do use locking, be very very careful if you use Apache::DBI or
> similar persistent connections. MySQL threads keep tables locked until
> the thread ends (connection is closed) or the tables are unlocked. If your
> session die()'s while tables are locked, they will stay neatly locked as
> your connection won't be closed either .... This was a nasty one I bumped
> in to ...
Unless you write a clean code that worries to clean up no matter what
happens to the script. This is a snippet from my DB handling code. It's a
part of the bigger OO module, but notice the DESTROY subroutine that
worries to unlock the tables and disconnect if you aren't using
Apache::DBI (if you do it's just a NOP)
######################################################################
# lock the passed tables in the requested mode (READ|WRITE) and set
# internal flag to handle possible user abortions, so the tables will
# be unlocked thru the END{} block
#
# sql_lock_tables('table1','lockmode',..,'tableN','lockmode'
# lockmode = (READ | WRITE)
#
# _side_effect_ $self->{lock} = 'On';
#
##########################
sub sql_lock_tables{
my $self = shift;
my %modes = @_;
return unless %modes;
my $do_sql = 'LOCK TABLES ';
$do_sql .= join ",", map {"$_ $modes{$_}"} keys %modes;
$self->{sth} = $self->{dbh}->prepare($do_sql);
$self->{sth}->execute();
# Enough to set only one lock, unlock will remove them all
$self->{lock} = 'On';
} # end of sub sql_lock_tables
######################################################################
# unlock all tables, unset internal flag to handle possible user
# abortions, so the tables will be unlocked thru the END{} block
#
# sql_unlock_tables()
#
# _side_effect_: delete $self->{lock}
#
##########################
sub sql_unlock_tables{
my $self = shift;
my $do_sql = 'UNLOCK TABLES ';
$self->{sth} = $self->{dbh}->prepare($do_sql);
$self->{sth}->execute();
# Enough to set only one lock, unlock will remove them all
delete $self->{lock};
} # end of sub sql_unlock_tables
# DESTROY makes all kinds of cleanups if the fuctions were interuppted
# before their completion and haven't had a chance to make a clean up.
###########
sub DESTROY{
my $self = shift;
$self->sql_unlock_tables() if defined $self->{lock};
$self->{sth}->finish if defined $self->{sth} and $self->{sth};
$self->{dbh}->disconnect if defined $self->{dbh} and $self->{dbh};
} # end of sub DESTROY
_______________________________________________________________________
Stas Bekman mailto:[EMAIL PROTECTED] http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org
single o-> + single o-+ = singlesheaven http://www.singlesheaven.com
