接続文字列

□未翻訳

□翻訳中

■翻訳完了(細田謙二)

■レビュー(Omi Chiba)

接続文字列

データベースとの接続は、DALのオブジェクトのインスタンスを作成することによって確立されます:

A connection with the database is established by creating an instance of the DAL object:

1.

>>> db = DAL('sqlite://storage.db', pool_size=0)

dbはキーワードではありません。つまり、それはローカルな変数で、接続オブジェクトDALを格納します。違う名前を付けても問題ありません。DALのコンストラクタは1つの引数、すなわち接続文字列を必要とします。接続文字列は、特定のバックエンドのデータベースに依存する唯一のweb2pyコードです。ここでは、サポートされているバックエンドのデータベースの特定のタイプに対する接続文字列の例を示します(すべてのケースで、データベースは、デフォルトのポートでtestという名前で、localhostから動作していることを想定しています):

db is not a keyword; it is a local variable that stores the connection object DAL. You are free to give it a different name. The constructor of DAL requires a single argument, the connection string. The connection string is the only web2py code that depends on a specific back-end database. Here are examples of connection strings for specific types of supported back-end databases (in all cases, we assume the database is running from localhost on its default port and is named "test"):SQLiteではデータベースが単一のファイルからなることに注意してください。ファイルが存在しない場合には、作成されます。このファイルはアクセスするたびにロックされます。MySQL、PostgreSQL、MSSQL。FireBird、Oracle、DB2、Ingres、Informixの場合、"test"データベースはweb2pyの外で作成される必要があります。接続が確立されると、web2pyは、テーブルを適切に作成、変更、削除します。

Notice that in SQLite the database consists of a single file. If it does not exist, it is created. This file is locked every time it is accessed. In the case of MySQL, PostgreSQL, MSSQL, FireBird, Oracle, DB2, Ingres and Informix the database "test" must be created outside web2py. Once the connection is established, web2py will create, alter, and drop tables appropriately.

接続文字列をNoneに設定することも可能です。この場合、DALはいかなるバックエンド・データベースにも接続しませんが、テスト用途としてAPIにはアクセス可能です。この例は、第7章で説明します。

It is also possible to set the connection string to None. In this case DAL will not connect to any back-end database, but the API can still be accessed for testing. Examples of this will be discussed in Chapter 7.

接続プール

Connection Pooling

DALのコンストラクタの2番目の引数はpool_sizeです。デフォルトでは0になります。

The second argument of the DAL constructor is the pool_size; it defaults to 0.

各リクエストに対して新規のデータベース接続を確立するのはそれなりに遅いので、web2pyは接続プール機構を実装しています。接続が確立されて、ページが処理され、トランザクションが完了すると、その接続は閉じられず、プールにされます。次のHTTPリクエストが来ると、web2pyはそのプールから接続を取得して、新規のトランザクションに利用しようと試みます。もしプールに利用可能な接続がないと、新しい接続が確立されます。

As it is rather slow to establish a new database connection for each request, web2py implements a mechanism for connection pooling. Once a connection is established and the page has been served and the transaction completed, the connection is not closed but goes into a pool. When the next http request arrives, web2py tries to obtain a connection from the pool and use that for the new transaction. If there are no available connections in the pool, a new connection is established.

pool_sizeパラメタは、SQLiteとGAEでは無視されます。

The pool_size parameter is ignored by SQLite and GAE.

プール内の接続は、スレッド間で順番に共有されます。つまり、それらは2つの異なるスレッドによって利用されますが、同時には利用されません。各web2pyのプロセスには1つのプールしかありません。

Connections in the pools are shared sequentially among threads, in the sense that they may be used by two different but not simultaneous threads. There is only one pool for each web2py process.

web2pyを起動した時は、プールは常に空です。プールは、pool_sizeの値か最大同時リクエスト数のどちらか少ない方まで成長します。つまり、pool_sizeが10でも、同時リクエスト数が5より多くなることはない場合、実際のプールサイズは5までしか成長しません。pool_size=0の場合は、接続プールは使用されません。

When web2py starts, the pool is always empty. The pool grows up to the minimum between the value of pool_size and the max number of concurrent requests. This means that ifpool_size=10 but our server never receives more than 5 concurrent requests, then the actual pool size will only grow to 5. If pool_size=0 then connection pooling is not used.

接続プールはSQLiteの場合は無視されます。特に恩恵がないからです。

Connection pooling is ignored for SQLite, since it would not yield any benefit.

接続の失敗

Connection Failures

web2pyがデータベースへの接続に失敗した場合、失敗を宣言する前に、1秒間待って、再び試みることを5回行います。接続プールの場合、プールされた接続のなかで、開いたままになっているが、しばらく利用されていないものは、データベース端末によって閉じることが可能です。再試行の機能のおかげで、web2pyは、それら切断された接続に対して再度、接続の確立を試みます。

If web2py fails to connect to the database it waits 1 seconds and tries again up to 5 times before declaring a failure. In case of connection pooling it is possible that a pooled connection that stays open but unused for some time is closed by the database end. Thanks to the retry feature web2py tries to re-establish these dropped connections.

複製されたデータベース

Replicated Databases

DAL(...)の最初の引数には、URIのリストをとることもできます。この場合、web2pyはそれらのそれぞれに接続しようと試みます。その主な目的は、複数のデータベースサーバーに対応し、それらの間で負荷を分散させることです。ここでは典型的なユースケースを示します:

The first argument of DAL(...) can be a list of URIs. In this case web2py tries to connect to each of them. The main purpose for this is to deal with multiple database servers and distribute the workload among them). Here is a typical use case:

1.

db = DAL(['mysql://...1','mysql://...2','mysql://...3'])

この場合、DALは最初のものに接続しようと試み、失敗したら、第2、第3のものに試みます。これは、マスタ-スレーブ構成のデータベースにおいて負荷を分散するためにも利用できます。詳細は、第11章においてスケーラビリティの文脈で説明します。

In this case the DAL tries to connect to the first and, on failure, it will they the second and the first. This can also be used to distribute load in a database master-slave configuration. We will talk more about this in Chapter 11 in the context of scalability.