Different methods of instantiation

The ScimoreDB Engine can be used in many different ways. This give high flexibility for the application developer to choose the methods that fits his application best. There are 5 ways of using the ScimoreDB engine. Switching between the models are very easy, and requires very little code changes.

At the bottom of this page, we have added a more schematic overview of the pro's and con's of the different instatiation modes.

Embedded in process

Instantiate the ScimoreDB engine inside your application. The database is loaded as DLL into your applications process space. The database is exclusively locked, so only your process can access it. The Scimore .NET data provider communicates directly with the database engine's memory. This is the fastest way to communicate with the ScimoreDB engine.

Use only this method, if you need the maximum speed and are sure what you are doing. You risk corrupting the memory of the database. For ScimoreDB Embedded, the prefered way of instatiation is "Embedded out of process", described in the following.

Embedded out of process

Instantiate the ScimoreDB engine in a seperate rundll process. The ScimoreDB process will start with the first program accessing the embedded database, and close 1 minute after the last program accessing the database, is closed.

All programs accessing the database will be communicating with the same ScimoreDB embedded process. The communication is very fast - using shared memory. This limits communication to the local machine.

This method of running embedded database is preferred, as it gives maximum safety and maximum flexibility at a very low speed cost.

Server

Install and run as a standalone service. Can be installed either using MSI, or using command line options for scimoredb.exe. It will run as its own service on the machine, using named pipes and tcp/ip for communication. It allows for other computers to connect and work with the database.

Standalone failover/failback cluster

ScimoreDB Server is a cluster aware application. Using shared disk and Microsoft Clustering Technology, you can configure a primary and standby ScimoreDB Server for failover and failback. Use this if you need high availability.

Distributed

Install on many machines, and cluster them into a single distributed sql environment. The cluster will appear as a single sql instance.

Schematic overview of pro's and con's.

	Pro's	Con's
Embedded in process	Faster than out-proc usage of DB No extra process for the DB	Not the most reliable solution, because the host process may corrupt/overwrite memory of scimoredb and therefore corrupt database. Hard to develop. Since DB is exclusivelly locked by host application, there is not possible to open and read DB by manager or other client. ScimoreDB may increase and steal the memory and CPU from host process. This is especially problematic when your application uses a lot of memory.
Embedded out of process	Runs in a separated process and is protected from memory corruptions by clients application Does not slow down and is not slow down by the client application Can be accessed by multiple programs and manager simultaniously	Use more PC resources Slower communicatino than an in-proc Creates a separate process "rundll32.exe", making the embedded db visible
Server	Allows external machines connecting to database. Run database independant of your appliations.	Visible footprint with ScimoreDB installed as service Need installation before using it Only TCP/IP protocol, could give problems with Firewall's
Distributed	Scale-out by using more machines.	Requires knowledge how to partition data when designing schema If unique indexes does not have key with partition column, the linear scalability cannot be achieved, so, it is trade-off between speed and schema design

ScimoreDB Embedded

Highlights