Project

General

Profile

DB Worker Node Add-on » History » Revision 7

Revision 6 (Udo Offermann, 03.04.2013 15:07) → Revision 7/14 (Udo Offermann, 03.04.2013 15:20)

h1. DB Worker Node Add-on 

 The *DB Worker Node Add-on* is a all-in-one-system z2 installation comprising the z2-Environment plus a database (at the moment "H2 Database Engine":http://www.h2database.com/ and "Apache Derby":http://db.apache.org/ are supported). The purpose is to have a quick and easy system setup like development or demonstration environments. Of course one can use it also for productive systems if H2 or Derby fulfills your requirements. 

 The add-on provides wrapper components that launches the actual database during the z2 bootstrap. Since the wrapper is launched on a separate z2 worker node (i.e. the DB Worker node) the database runs in server mode from the web applications point of view (which are running on the web worker node).  

 h2. Using the DB Worker Node Add-on 

 At first you have to tell the z2-Environment where to find the DB Worker Node Add-on. Usually this is done in the _environment_ module which is used to describe the overall system setup. The file @dbWorkerAddon.properties@ attached   

 In order to this page is run the database within a z2 repository component for this add-on which you can directly add separate process one has to configure the _environment_. DB worker node in the *com.zfabrik.db.environment* module 

 The second step is following files must be added or changed in the environment in order to launch run the DB worker in addition node: 
 * *dbWorkerRepository.properties* (new file): this _z2 component repository_ points to this Add-on git repository. 
 * *dbWorker.properties* (new file): component containing JVM settings for the web DB worker (and maybe also a job worker). The so called node like Java heap size, debug port etc. 
 * *home.properties* (changed file): the _home layout_ is defined inside @environment/home.properties@. Attached component lists all workers to this page is a modified @home.properties@ that launches start in the given order. It's recommended to start the DB worker and afterwards the web worker. You can simply replace the existing @home.properties@ file node before all other nodes: @home.workers=environment/dbWorker,environment/webWorker@. 
 * *dbWorkerUp.properties* (new file): this _z2 system state_ is attained by this attached version or change the property manually: 

 <pre> dbWorker component. 
 com.zfabrik.component.type=com.zfabrik.homeLayout 
 home.workers = com.zfabrik.db.environment/h2Worker, environment/webWorker 
 </pre> 

 Please note that @com.zfabrik.db.environment/h2Worker@ comes first so that * *h2DatabaseServer.properties* (new file): the H2 database launcher component participates in the dbWorkerUp system state, thus it will be launched inside the separate JVM of the DB is up and running before the web worker is started.  
 To use Derby instead of node. This component contains also several H2 you simply replace command arguments like TCP port, ssl mode etc (see the @home.workers@ by documentation of the @main@    method at http://www.h2database.com/javadoc/org/h2/tools/Server.html for more details). 

 <pre> 
 home.workers = com.zfabrik.db.environment/derbyWorker, environment/webWorker 
 </pre> 

 The DB worker node is fully transparent to the web applications so there is no need applications. Thus the remaining steps are the same as for further changes. any other external databases: 
 * *systemDB.properties*: contains the h2 connection string (see also http://www.h2database.com/html/features.html#database_url) 
 * *samplesDB.properties*: the samples DB contains the name of the sample database plus its credentials 

 As usual you have to make sure mentioned before the database is started as the first node during the overall z2 bootstrap process so that the applications on database is available before the web worker applications are using the corresponding JDBC drivers and started. The database client settings (connection string, user and password etc). Also schema can be generated using migration tools like flyway or other flyway, automatic schema generation feature as provided from hibernate or simply by hibernate for example can be used as usual. using the database specific DDL via JDBC.