User's Guide
PART 3. Java in the Database
CHAPTER 17. Using Java in the Database
Java values are stored in serialized form. This means that each row contains the following information:
A version identifier
An identifier for the class (or subclass) that is stored.
The values of public fields in the class
Other overhead information
The class definition is not stored for each row. Instead, the identifier provides a reference to the class definition, which is held only once.
You can use Java objects without knowing the details of how these pieces work, but the way in which the objects are stored does have some implications for performance and so information is provided here.
Disk space The overhead per row is on around 10 to 15 bytes. If the class has a single variable, then the storage required for the overhead can be similar to the amount needed for the variable itself. If the class has many variables, the overhead is negligible.
Performance Any time a Java value is inserted or updated, it needs to be serialized by the Java VM. Any time a Java value is retrieved in a query, it needs to be deserialized by the VM. This can amount to a significant performance penalty.
You can avoid the performance penalty for queries by using computed columns.
Indexing Indexes on Java columns will not be very selective, and will not provide the performance benefits associated with indexes on simple SQL data types.
Java objects and class versionsJava objects stored in the database are persistent; that is, they exist even when no code is running. This means that you could carry out the following sequence of actions:
Install a class.
Create a table using that class as the data type for a column.
Insert rows into the table.
Install a new version of the class.
How will the existing rows work with the new version of the class?
Adaptive Server Anywhere provides a form of class versioning to allow the new class to work with the old rows. The rules for accessing these older values are as follows:
If a serializable field is in the old version of the class, but is either missing or not serializable in the new version, the field is ignored.
If a serializable field is in the new version of the class, but was either missing or not serializable in the old version, the field is initialized to a default value. The default value is 0 for primitive types, false for Boolean values, and NULL for object references.
If there was a superclass of the old version that is not a superclass of the new version, the data for that superclass is ignored.
If there is a superclass of the new version that was not a superclass of the old version, the data for that superclass is initialized to default values.
If a serializable field changes type between the older version and the newer version, the field is initialized to a default values. Type conversions are not supported; this is consistent with Sun Microsystems serialization.
A serialized object is not accessible if the class of the object or any of its superclasses has been removed from the database, at any time. This behavior is consistent with Sun Microsystems serialization.
These changes make cross database transfer of objects possible even when the versions of classes differ. Cross database transfer can occur as follows:
Objects are replicated to a remote database.
A table of objects is unloaded and reloaded into another database.
A log file containing objects is translated and applied against another database.
The class definition for each class is loaded by each connection's VM the first time that class is used.
When you INSTALL a class, the VM on your connection is implicitly restarted. Therefore, you have immediate access to the new class.
For connections other than the one that carries out the INSTALL, the new class is loaded the next time a VM accesses the class for the first time. If the class is already loaded by a VM, that connection does not see the new class until the VM is restarted for that connection (for example, with a STOP JAVA and START JAVA).