Space Databases (Magic xpa 3.x)
The Space database provides access to a GigaSpaces In Memory Data Grid (IMDG) space from a Magic xpa application. Space databases can be used:
-
To store temporary data shared with all servers.
-
To store a large cache of database tables mainly for performance enhancements.
-
To mirror the data in the database and act as the main source of data for the application. The space is responsible for updating the database asynchronously. GigaSpaces provides the opportunity to work with asynchronous persistency in what’s referred to as Write Behind mode, which provides the ability to handle extremely large transaction workloads. The data is uploaded to the space from a backend database. When this data is changed in the space via a Magic xpa application, Hibernate then does the work of updating the database server. The Space database allows access to the data that is connected to the application, while significantly improving performance and ensuring that data is not lost.
|
Note:
|
-
The Space database requires a special license.
-
To use the Space database, you need to install the GigaSpaces middleware (even if you want to use the broker as a middleware).
-
There is no need to define the Space gateway in the Magic.ini file. This gateway is loaded automatically.
-
The Studio allows access to an external (non-embedded) space or an embedded space. During deployment, there is only access to an external space. For more information, see the Embedded Spaces section below.
-
In Space databases, the data sources and column names are case sensitive. When creating data sources manually or when using a DB SQL Where clause, make sure to you use the correct case.
|
The following data types and internal storages are supported:
|
Attribute
|
Internal Storage
|
|
Alpha
|
Zstring
|
|
Unicode
|
Zunicode
|
|
Numeric
|
Signed Integer, Float, String Number
|
|
Logical
|
Integer Logical
|
|
Date
|
String Date
|
|
Time
|
String Time
|
|
Blob
|
All Blob content types
|
The following is information about working with the Space database:
|
Position
|
-
A Unique index is a single segment unique index. The unique index segment field cannot be updated.
-
Table with more than one unique index – If there is a table with more than one unique index in a Space database and the table is partitioned on more than one partition, the routing ID is set on the position segment field and the Space database will not enforce uniqueness on the other index(es). This is because the Space database only checks for uniqueness within one partition.
-
If the position index in the table is different than the position index in the task, the Order By clause will not work properly.
|
|
Transactions and Locking
|
-
Physical and deferred transactions are supported.
-
Locking a single record within a transaction is currently not supported.
-
Locking an entire data view is not supported.
|
|
Sort/Temporary Database
|
Space databases cannot be the database for Sort or Temporary tables.
|
|
Direct SQL
|
Space databases cannot be used as the Database or the Result Database for Direct SQL tasks. As of V3.1, Direct SQL can be used for execution commands (commands that do not retrieve records).
|
|
Data Range
|
For non-interactive tasks, when using a Space data source, if the data source has lots of records, you should always select a range of records. If you do not use a range, the ID of all the records will be fetched and Magic xpa will work slowly.
|
|
Data Source properties
|
The following data source properties are not supported:
-
Cursor
-
Database information
-
Owner
-
Resident
-
Table type
|
|
Column properties
|
The following column properties are not supported:
|
|
Database properties
|
The Check Existence property is not supported. The data source will always be created if it does not exist.
|
|
Non-supported functions
|
The following functions are not supported:
-
DbReload
-
DbRound
-
ErrDatabaseName
-
ErrDbmsCode
-
ErrMagicName
-
ErrPosition
-
ErrTableName
|
|
Other limitations
|
-
Link Join and Get File definition are currently not supported.
-
The data source objects in the space do not support special characters in their name, such as #. These characters are replaced with an underscore. The original name is kept in the data source's Information for SQL Database property and in the column’s Database Information property.
-
Renaming a data source that already exists on the space requires a restart of the space. This is done automatically on embedded spaces and should be done manually for non-embedded spaces.
-
When using a constant value in the SQL Where clause, it will be trimmed according to the SQL type. If no SQL type is defined, the value will be trimmed for Unicode columns and will not be trimmed for Alpha columns.
-
For the DB SQL Where and Magic SQL clause, a field name on the right side of an expression is not supported. For example, the following is not supported: a = a1.
-
If a column was previously defined with the Type column property set to IDENTITY and this column is used as the unique index column, when creating a new record, you need to set a value in this column.
-
When using the Automatic Program Generator (APG) for Space databases, creating two indices that have the same field is not supported.
|
An embedded space allows you to use the In Memory Data Grid in a temporary space running under the Studio. While developing, it is recommended to use an embedded space since some data source manipulations require restarting the space and if the space is embedded, the restart is done automatically.
For an embedded space, enter EMBEDDED=Y in the Database Information field located in the Database Properties dialog box. Note that the Studio allows access to an embedded space, but the Runtime engine does not.
|
|
The Magic xpa Single User Edition does not support the Space database.
|
