Table of Contents

Editing Schema Connection Settings

You can edit the connection settings for an Instant JChem Schema. This allows you to change the database connection details and remove any stored usernames and passwords so that different ones can be used next time you login. This is only really useful for remote databases as all settings for a local database are usually implicitly defined.

You can only edit the connection settings when you are disconnected from the Schema. You can disconnect from a Schema by right clicking in its node in the project explorer and choosing 'Close connection...'.

When disconnected from the Schema right click on its node in the project explorer and select 'Connection settings...'. A dialog will open that lets you edit the settings.

In this dialog you can edit the connection details and specify that you do not want to store your usernames and passwords. You will be prompted for those that are not stored next time you connect. This allows you to change a username of password that might have been stored. You can also specify whether you want to be connected automatically when IJC starts.

Configuring connection pool

Configurable connection pool is a new cool feature in IJC 5.8 configurable only by editing *.ijc file at the moment. It's supported by Derby db and can be used with MySQL and Oracle as well. Configuration of schema settings is stored in project folder/.cofig/IJC_shema_name.ijc. Extra setting related to connection to database must be add manually to this file. You can make data retrieval faster if you properly specify behaviour of concurrent connections.

Since IJC 5.8 defaults are changed to impose less overhead on the db machine. Explanation of each parameter you can set is given at http://commons.apache.org/pool/apidocs/org/apache/commons/pool/impl/GenericObjectPool.html.

Following properties can be set:

<entry key="custom.connection.pool">true</entry>
<entry key="custom.connection.pool.maxActive">6</entry>
<entry key="custom.connection.pool.whenExhaustedAction">1</entry>
<entry key="custom.connection.pool.maxWait">10000</entry>
<entry key="custom.connection.pool.maxIdle">1</entry>
<entry key="custom.connection.pool.minIdle">0</entry>
<entry key="custom.connection.pool.testOnBorrow">true</entry>
<entry key="custom.connection.pool.testOnReturn">true</entry>
<entry key="custom.connection.pool.timeBetweenEvictionRunsMillis">20000</entry>
<entry key="custom.connection.pool.numTestsPerEvictionRun">2</entry>
<entry key="custom.connection.pool.minEvictableIdleTimeMillis">120000</entry>
<entry key="custom.connection.pool.testWhileIdle">true</entry>
<entry key="custom.connection.pool.softMinEvictableIdleTimeMillis">-1</entry>
<entry key="custom.connection.pool.lifo">true</entry>

Few examples

For example if we decide to reduce the pool size to 2 and prevent any idle connection being left in the pool we can add the following three elements to the ijs file.

<entry key="custom.connection.pool">true</entry>
<entry key="custom.connection.pool.maxActive">2</entry>
<entry key="custom.connection.pool.maxIdle">0</entry>

Another sample which shows that we create a pool with two connections and the eviction is disabled so the connection will stay alive in the connection pool:

<entry key="custom.connection.pool">true</entry>
<entry key="custom.connection.pool.maxActive">2</entry>
<entry key="custom.connection.pool.minEvictableIdleTimeMillis">-1</entry>

Another sample can be a more complex config like having a maximum of 8 connections in the pool but evict them quickly after they became idle. This allows the users that uses the 5.9+ on a multicore machine to benefit from parallelism in data retrieval when using charts, reports and personal server.

<entry key="custom.connection.pool">true</entry>
<entry key="custom.connection.pool.maxActive">8</entry>
<entry key="custom.connection.pool.timeBetweenEvictionRunsMillis">5000</entry>
<entry key="custom.connection.pool.minEvictableIdleTimeMillis">30000</entry>

Also note that reducing the size of the pool will generally make the application slower as all database access should happen serially specially when we have reporting with large number of records or doing the charts in the 5.9 and onward because of the fact that we use parallel data retrieval.

---