Test Mode Ups In Memory

[Shima Costar]

Pipelineworks for me in test mode, but after running analysis whole computer stuck in 2 min. Even moving with mouse is impossible.

Some collegues came back to v.2.0 because 2.1 made their computer fall down.

Since CP 2.1 involves such significant changes from 2.0, it is not feasible to export to a prior version. Your best bet is to have both versions open at the same time and mirror the modules/settings manually.

I ran the pipeline and image sets on my computer (8 cores / 8gb memory / windows 7 x64 / 8 workers) and experienced no problems. You can try the Windows 64 build from the trunk builds page (cellprofiler.org/cgi-bin/trunk_build.cgi) - it is pretty close to what I am running.

In embedded mode, an application opens a database from within the same JVM using JDBC.This is the fastest and easiest connection mode.The disadvantage is that a database may only be open in one virtual machine (and class loader) at any time.As in all modes, both persistent and in-memory databases are supported.There is no limit on the number of database open concurrently,or on the number of open connections.

In embedded mode I/O operations can be performed by application's threads that execute a SQL command.The application may not interrupt these threads, it can lead to database corruption,because JVM closes I/O handle during thread interruption.Consider other ways to control execution of your application.When interrupts are possible the async:file system can be used as a workaround, but full safety is not guaranteed.It's recommended to use the client-server model instead, the client side may interrupt own threads.

When using the server mode (sometimes called remote mode or client/server mode),an application opens a database remotely using the JDBC or ODBC API.A server needs to be started within the same or another virtual machine, or on another computer.Many applications can connect to the same database at the same time, by connecting to this server.Internally, the server process opens the database(s) in embedded mode.

The server mode is slower than the embedded mode, because all data is transferred over TCP/IP.As in all modes, both persistent and in-memory databases are supported.There is no limit on the number of database open concurrently per server,or on the number of open connections.

The mixed mode is a combination of the embedded and the server mode.The first application that connects to a database does that in embedded mode, but also startsa server so that other applications (running in different processes or virtual machines) canconcurrently access the same data. The local connections are as fast as ifthe database is used in just the embedded mode, while the remoteconnections are a bit slower.

The server can be started and stopped from within the application (using the server API),or automatically (automatic mixed mode). When using the automatic mixed mode,all clients that want to connect to the database (no matter ifit's an local or remote connection) can do so using the exact same database URL.

For certain use cases (for example: rapid prototyping, testing, high performanceoperations, read-only databases), it may not be required to persist data, or persist changes to the data.This database supports the in-memory mode, where the data is not persisted.

In some cases, only one connection to a in-memory database is required.This means the database to be opened is private. In this case, the database URL isjdbc:h2:mem: Opening two connections within the same virtual machinemeans opening two different (private) databases.

Sometimes multiple connections to the same in-memory database are required.In this case, the database URL must include a name. Example: jdbc:h2:mem:db1.Accessing the same database using this URL only works within the same virtual machine andclass loader environment.

To access an in-memory database from another process or from another computer,you need to start a TCP server in the same process as the in-memory database was created.The other processes then need to access the database over TCP/IP or TLS,using a database URL such as: jdbc:h2:tcp://localhost/mem:db1.

By default, closing the last connection to a database closes the database.For an in-memory database, this means the content is lost.To keep the database open, add ;DB_CLOSE_DELAY=-1 to the database URL.To keep the content of an in-memory database as long as the virtual machine is alive, usejdbc:h2:mem:test;DB_CLOSE_DELAY=-1.This may create a memory leak, when you need to remove the database, usethe SHUTDOWN command.

By default, a new database is automatically created if it does not exist yetwhen the embedded url is used.To create an encrypted database, connect to it as it would already exist locally using the embedded URL.

The encryption algorithm is set in the database URL, and the file password is specified in the password field,before the user password. A single space separates the file passwordand the user password; the file password itself may not contain spaces. File passwordsand user passwords are case sensitive. Here is an example to connect to apassword-encrypted database:

To encrypt an existing database, use the ChangeFileEncryption tool.This tool can also decrypt an encrypted database, or change the file encryption key.The tool is available from within the H2 Console in the tools section, or you can run it from the command line.The following command line will encrypt the database test in the user home directorywith the file password filepwd and the encryption algorithm AES:

Whenever a database is opened, a lock file is created to signal other processesthat the database is in use. If database is closed, or if the process that openedthe database terminates, this lock file is deleted.

By default, when an application calls DriverManager.getConnection(url, ...)with embedded URL and the database specified in the URL does not yet exist,a new (empty) database is created.In some situations, it is better to restrict creating new databases, and only allow to openexisting databases. To do this, add ;IFEXISTS=TRUEto the database URL. In this case, if the database does not already exist, an exception is thrown whentrying to connect. The connection only succeeds when the database already exists.The complete URL may look like this:

Usually, a database is closed when the last connection to it is closed. In some situationsthis slows down the application, for example when it is not possible to keep at least one connection open.The automatic closing of a database can be delayed or disabled with the SQL statementSET DB_CLOSE_DELAY .The parameter specifies the number of seconds to keepa database open after the last connection to it was closed. The following statementwill keep a database open for 10 seconds after the last connection was closed:

By default, a database is closed when the last connection is closed. However, if it is never closed,a persistent database is closed when the virtual machine exits normally, using a shutdown hook.In some situations, the database should not be closed in this case, for example because thedatabase is still used at virtual machine shutdown (to store the shutdown process in the database for example).For those cases, the automatic closing of the database can be disabled in the database URL.The first connection (the one that is opening the database) needs toset the option in the database URL (it is not possible to change the setting afterwards).The database URL to disable database closing on exit is:

Sometimes, particularly for in-memory databases, it is useful to be able to execute DDL or DMLcommands automatically when a client connects to a database. This functionality is enabled viathe INIT property. Note that multiple commands may be passed to INIT, but the semicolon delimitermust be escaped, as in the example below.

Backslashes within the init script (for example within a runscript statement, to specify the folder names in Windows)need to be escaped as well (using a second backslash). It might be simpler to avoid backslashes in folder names for this reason;use forward slashes instead.

Some applications (for example OpenOffice.org Base) pass some additional parameterswhen connecting to the database. Why those parameters are passed is unknown.The parameters PREFERDOSLIKELINEENDS andIGNOREDRIVERPRIVILEGES are such examples;they are simply ignored to improve the compatibility with OpenOffice.org. If an applicationpasses other parameters when connecting to the database, usually the database throws an exceptionsaying the parameter is not supported. It is possible to ignored such parameters by adding;IGNORE_UNKNOWN_SETTINGS=TRUE to the database URL.

In addition to the settings already described,other database settings can be passed in the database URL.Adding ;setting=value at the end of a database URL is thesame as executing the statement SET setting value just afterconnecting. For a list of supported settings, see SQL Grammaror the DbSettings javadoc.

Usually, the database opens the database file with the access moderw, meaning read-write (except for read only databases,where the mode r is used).To open a database in read-only mode if the database file is not read-only, useACCESS_MODE_DATA=r.Also supported are rws and rwd.This setting must be specified in the database URL:

If you want to access the same database at the same time from different processes or computers,you need to use the client / server mode. In this case, one process acts as the server, and theother processes (that could reside on other computers as well) connect to the server via TCP/IP(or TLS over TCP/IP for improved security).

This database is multithreading-safe.If an application is multi-threaded, it does not need to worry about synchronizing access to the database.An application should normally use one connection per thread.This database synchronizes access to the same connection, but other databases may not do this.To get higher concurrency, you need to use multiple connections.

Usually, SELECT statements will generate read locks. This includes subqueries.Statements that modify data use write locks on the modified rows.It is also possible to issue write locks without modifying data,using the statement SELECT ... FOR UPDATE.Data definition statements may issue exclusive locks on tables.The statements COMMIT andROLLBACK releases all open locks.The commands SAVEPOINT andROLLBACK TO SAVEPOINT don't affect locks.The locks are also released when the autocommit mode changes, and for connections withautocommit set to true (this is the default), locks are released after each statement.The following statements generate locks:

3a8082e126