Database

Each deployment site needs a database to implement the persistency behavior of the business model. Netsilon currently supports MySQL 3.22.32 or more and Oracle 8 or more.

! The database described must be created with correct rights by the system administrator in order to be formatted and managed by Netsilon.

During deployment, Netsilon is able to modify incrementally the schema of a database if this one is accessible on line. If the database is not accessible on line :

• make a local copy of the database, let Netsilon update the local database and reinstall the modified database in the target server
• during deployment, choose to skip online database update and generate a SQL script. The file SQL Script.txt in the project folder will contain the DDL commands to create the whole database schema. It is however not recommended to follow this method since Netsilon must also update the contents of the database if classes are deleted in the business model.

Properties

Name	Name of the database description. For information only.
RDBMS	Name of the Relational Database Management System (read only)
Data access	Specifies which driver will be used to access the RDBMS Through local driver: JSP, Servlet: Netsilon stores a jdbc driver in the generated web application and the scripts use it. The driver to use is described by the properties below. Through application server: PHP: the generated scripts always use the driver provided by the PHP application server JSP, Servlet: the generated scripts use the driver specified in the configuration of the application server. JNDI is used to find this driver.
Class name of the jdbc driver	JSP, Servlet: Java class name of the jdbc driver used in the generated web application. MySQL: defaults to org.gjt.mm.mysql.Driver Oracle: defaults to oracle.jdbc.driver.OracleDriver
Path to the driver library	JSP, Servlet: Path to the java library that contains the jdbc driver used in the generated web application. This driver will be transferred in the directory Web-inf/lib during generation. MySQL: defaults to <installpath>/mysql.jar Oracle: defaults to <installpath>/oracle12.jar The pattern <installpath> refers to the folder where Netsilon is installed. The pattern <projectpath> refers to the project folder.
Transactions	None: Netsilon does not emit transaction related instructions Local transactions: each dynamic page is executed in a transaction. However, the target RDBMS must support transactions if this option is selected (until recently MySQL did not support transactions). Transaction support in PHP is partial since Netsilon can not catch exceptions in PHP. Distributed transactions: JSP, Servlet: when data access is done through the application server, this option can be selected in order to execute each dynamic page in distributed transactions. If distributed transactions are under the control of the application server, None may preferably be selected.
Database or sid	MySQL: name of the database created by the system administrator Oracle: sid of the database created by the system administrator
Prefix all tables with	If not empty, all table names created and managed by Netsilon are prefixed with this string. During deployment, Netsilon reads the current database schema and modifies incrementally this schema to apply modifications done in the business model. If the prefix is empty, all tables not managed by Netsilon will be deleted. If the prefix is not empty, every tables whose name does not start with the prefix are left untouched by Netsilon.
DB access in the IDE Server Name	Name of the server on which runs the RDBMS when Netsilon communicates with it. MySQL: for example: stagingMySQL Oracle: for example: stagingOracle:1521
DB access in the IDE User	Name of the user able to modify the database schema and contents when Netsilon communicates with the server.
DB access in the IDE Password	Password of the user able to modify the database schema and contents when Netsilon communicates with the server.
DB access in the generated scripts Server Name ( sid )	PHP: Name or sid of the server on which runs the RDBMS when the generated web application communicates with it. MySQL: host name, for example: localhost Oracle: sid name, for example: TESTDB JSP, Servet: jdbc or jndi connection string to the server on which runs the RDBMS RDBMS when the generated web application communicates with it. MySQL: for example: jdbc:mysql://localhost/stagingMySQL Oracle: for example: jdbc:oracle:thin:@stagingOracle:1521:TESTDB
DB access in the generated scripts Roles	A list of named roles that identify the user able to modify the database contents when the generated application communicates with the server. Generally there should only be one role, the default role. If more roles are defined, the generated application can programmatically switch from one role to the other. In fact, the current connection to the database is closed and a new one is opened with the new role. Use operation setDatabaseRole from class System to switch roles. If roles are used, all database that identifies the same one in every deployment site should have the same name. A role is defined by: its name: identifies the role in the setDatabaseRole operation a user name: the name of the user able to modify the database contents when the generated application communicates with the server a password: password of the user able to modify the database contents when the generated web application communicates with the server.

Transactions

Application domain

A transaction reflects a sequence of instructions considered as atomic and the effects as a whole can be cancelled if an error occurs. Netsilon uses the support offered by the database management system that it targets. Thus, only Oracle is able to be targeted for the use of the transactions at the present time. A transaction does have a meaning if there is a mean to detect the occurrence of an error. But it is not possible to detect the errors during the execution of a script PHP; therefore only Java is usable. The scope of the transactions is: JSP/Servlet and Oracle.

Operations covered by a transaction

If a web application uses local transactions, the execution of a page is entirely done in a transaction. Netsilon has no smaller notion of a transaction. Moreover, Oracle does not permit nested transactions. In fact, the management of the session life cycle is done in a transaction, then the execution of the effective instructions of the page is done in a transaction. If an error occurs during the execution of these instructions, the transaction is rollback and modifications cancelled.

If a web application uses distributed transactions, the application server handles the domains covered by transactions. Netsilon is able or not to produce explicit code to begin and end transactions. If it is preferable to let the application server manage transactions, choose None for the property Transaction of the database.

Transaction types

Netsilon supports the four types of transaction isolation. However, Oracle only handles ReadCommited and Serializable. ReadCommited is the default transaction, it can however produce ghost reads. Serializable is the most reliable transaction but also the slowest.