Difference between revisions of "Design Specs: Database Connectivity"
Line 12: | Line 12: | ||
Currently, each database is a "Service". When the API is instantiated, connections are made to each required service. Database handles are cached. When a database handle is needed, the service first checks to see if it is live, if not it refreshes the connection. This would probably be the ideal location to implement failover -- check the current connection, if dead, try a different database server. | Currently, each database is a "Service". When the API is instantiated, connections are made to each required service. Database handles are cached. When a database handle is needed, the service first checks to see if it is live, if not it refreshes the connection. This would probably be the ideal location to implement failover -- check the current connection, if dead, try a different database server. | ||
+ | |||
+ | Failover can be implemented through Moose method modifier 'around' | ||
+ | around 'dbh' => sub { | ||
+ | my $orig = shift; | ||
+ | my $self = shift; | ||
+ | |||
+ | my $species = $self->species; | ||
+ | |||
+ | # Do we already have a dbh? HOW TO TEST THIS WITH HASH REF? | ||
+ | if ($self->has_dbh) { | ||
+ | $self->log->debug(" gff-dbh for $species exists and is alive!"); | ||
+ | return $self->$orig; | ||
+ | } else { | ||
+ | $self->log->debug(" gff-dbh for $species doesn't exist yet; trying to connect"); | ||
+ | my $dbh = $self->connect($species); | ||
+ | } | ||
+ | }; | ||
+ | |||
Note also that these Services use Moose "Roles" to define shared methods and variables like connect(). | Note also that these Services use Moose "Roles" to define shared methods and variables like connect(). | ||
Revision as of 16:56, 10 February 2010
Objectives
Part of the WormBase::API. Needs to be able to connect to multiple databases (multiple instances of the same database in some cases). Should be fault tolerant if a server or database crashes.
Resources
The current connectivity code is part of the API. The API, in turn, is inside of the lib directory of the WormBase mercurial repository:
http://bitbucket.org/tharris/wormbase/src/tip/lib/WormBase/API/Service/
Currently, each database is a "Service". When the API is instantiated, connections are made to each required service. Database handles are cached. When a database handle is needed, the service first checks to see if it is live, if not it refreshes the connection. This would probably be the ideal location to implement failover -- check the current connection, if dead, try a different database server.
Failover can be implemented through Moose method modifier 'around' around 'dbh' => sub { my $orig = shift; my $self = shift; my $species = $self->species; # Do we already have a dbh? HOW TO TEST THIS WITH HASH REF? if ($self->has_dbh) {
$self->log->debug(" gff-dbh for $species exists and is alive!"); return $self->$orig;
} else {
$self->log->debug(" gff-dbh for $species doesn't exist yet; trying to connect"); my $dbh = $self->connect($species);
} };
Note also that these Services use Moose "Roles" to define shared methods and variables like connect().
Here's the acedb service:
http://bitbucket.org/tharris/wormbase/src/tip/lib/WormBase/API/Service/acedb.pm
The acedb service "consumes" the generic Service role:
http://bitbucket.org/tharris/wormbase/src/9009075c4c5a/lib/WormBase/API/Role/Service.pm
This nomenclature and structure is a bit confusing and probably needs to be streamlined/refined!!