Date: Thu, 28 Mar 2024 10:34:02 +0000 (UTC) Message-ID: <831684422.10623.1711622042173@911f0a1bad02> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_10622_794104839.1711622042172" ------=_Part_10622_794104839.1711622042172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
At its core, Servoy is a comprehensive platform to develop datab= ase-driven applications. As such, Servoy allows developers to connect to an= y standard Relational Database Management System (RDBMS). To achieve this, = Servoy employs Java Database Connectivity (JDBC) technology. JDBC is a conn= ectivity standard that allows Java-based applications to interact transpare= ntly with any database vendor that provides a compliant driver
The Servoy platform uses Structured Query Language (SQL), a standard com= munications protocol to issue requests to databases. The traditional develo= pment of database applications typically requires advanced SQL knowledge to= adequately and efficiently retrieve data. Moreover, database vendors often= adapt their own "flavors" of SQL, making database portability an issue. If= an application uses non-standard SQL expressions, it cannot be easily depl= oyed against databases other the the one for which it was developed.
The Servoy platform obviates the need for developers to write their own = SQL in almost all scenarios. Instead Servoy dynamically generates all the S= QL required to read and write data for all but the most complex scenarios. = Servoy's generated queries are guaranteed to be optimized and database-neut= ral. At the same time, the Servoy platform is open and allows developers wi= th the knowledge and preference for writing SQL to do so as well.
Developers will specify a Server Name, which maps to a specific= database connection configuration (i.e. user, password, URL, etc). At run = time, Servoy will automatically create a pool of connections for a given Se= rver Name, which will be reused for the duration of the application server = up time. Developers are always insulated from the complexities of connectin= g to the database.
The details of a connection configuration are stored as part of the deve= lopment or deployment environment and are never part of the code base. This= allows the database connection to be changed for a given context without m= aking modifications to an application's code base.
For example, it is common to have separate databases for development/tes= ting and production. Therefore, a Server Name could resolve to a test datab= ase in both Servoy Developer and an instance of Servoy Server used for stag= ing. The same Server Name would resolve to a production database for an ins= tance of Server Server used in production. Another example is for multiple,= on-premise, deployments where local instances of Servoy Server rely on loc= al database connections.
While database connections can be changed transparently between differen= t development and deployment contexts, they can also be changed within the = same context. Servoy's API provides a means for developers to change, at ru= n time, from one Server Name to another. For example, different application= user groups may be required to use different connections to the same datab= ase. In another example, different customers may have their data stored in = their own separate database. In both these cases, a specific Server Name is= identified and used for an individual client session.
Servoy uses database connection pooling technology which provides signif= icant benefits in terms of application performance, concurrency and scalabi= lity. Database connections are often expensive to create because of the ove= rhead of establishing a network connection and initializing a database conn= ection session in the back end database. Moreover, the ongoing management o= f all of a database's connection sessions can impose a major limiting facto= r on the scalability of an application. Valuable database resources such as= locks, memory, cursors, transaction logs, statement handles and temporary = tables all tend to increase based on the number of concurrent connection se= ssions. This limitation is overcome using Connection Pooling, whereby a lim= ited number of connections is shared by a larger number of clients. When a = client makes a new request for data, the application server briefly borrows= a connection from the pool to issue the query, then returns it to the pool= . In this manner an application can scale well beyond the limits of the dat= abase without compromising performance. Servoy's connection pools are confi= gurable so that connectivity can be optimized to suit applications of vario= us sizes.