This chapter discusses issues that will help improve the performance, reliability, and size of JDataStore applications. Unless otherwise specified,JDataStore is a feature of JBuilder Professional and Enterprise, and the Inprise Application Server.
DataStoreConnection
refers to either a DataStoreConnection
or DataStore
object used to open a connection to a JDataStore file.
DataStoreConnection.close()
when the DataStoreConnection
is no longer needed, or call DataStore
.shutdown()
to close the JDataStore file regardless of how many connections there may be. In particular,
System.exit()
until you have called DataStore.shutdown()
.
Closing a JDataStore ensures that all modifications are saved to disk. There is a
daemon thread for all open DataStoreConnection
instances that is constantly saving modified
cache data (by default modified data is saved every 100 milliseconds). If you directly exit the Java VM, the daemon thread might not have the opportunity to save the last set of changes. There is a small chance that a non-transactional JDataStore may get corrupted.
A transactional JDataStore is guaranteed to not lose data, but the transaction manager rolls back any uncommitted changes.
If a JDataStore file isn't closed properly, it takes several seconds to reset/recover the JDataStore file. Proper closure means that the JDataStore reopens quickly every time.
Another benefit to closing DataStoreConnection
objects is that when they are all closed, the memory allocated to the JDataStore cache is released.
Close all StorageDataSet
s that have their store
property set to a DataStoreConnection
when you are done with them. This frees up JDataStore
resources associated with the StorageDataSet
and allows the StorageDataSet
to be
garbage collected.
saveMode
property of the DataStore
component to control how often cache blocks are written to disk. This property applies only to non-transactional JDataStores. The following are valid values for the method:
1: Save immediately when blocks are added or deleted; let the daemon thread handle all other changes. This is the default mode. Performance is almost as good as with saveMode(0)
.
2: Save all changes immediately. Use this setting whenever you debug an application that uses a DataStore
.
Unlike other properties of DataStore
, saveMode
can be changed when the connection is open. For example, if you are using a DataStoreConnection
, you can access the value through the dataStore
property:
DataStoreConnection store = new DataStoreConnection(); // ... store.getDataStore().setSaveMode(2);
Note that this changes the behavior for all DataStoreConnection
objects that access that particular JDataStore file.
You might try increasing the DataStore
.minCacheBlocks
property, which controls the minimum number of blocks that are cached.
The DataStore
.maxSortBuffer
property controls the maximum size of the buffer used for in-memory sorts. Sorts that exceed this buffer size use a slower disk-based sort.
DataStore
.tempDirName
property, used by the query engine, to a directory on another (fast) disk drive might help.
Try setting the TxManager
.checkFrequency
higher. Higher values results in slower recovery, but why be pessimistic?
For simple operations, DataExpress might be faster than JDBC/SQL. JDBC/SQL is probably faster for more complex queries.
Try to write your applications with efficient multithreading. Attempt to keep the number of monitor objects to a minimum to take advantage of multi-processor systems.
DBDisposeMonitor
(which automatically disposes of data-aware component resources when a container is closed) has a closeDataStores
property. When true (the default), it automatically closes any JDataStores attached to components it cleans up.
For example, if you drop a DBDisposeMonitor
into a JFrame
you're designing that contains dbSwing components attached to a JDataStore, when you close the JFrame
, DBDisposeMonitor
automatically closes the JDataStore for you. This component is particularly handy when building simple applications to experiment with JDataStore.
DBExceptionHandler
has an Exit button. You can hide it with a property setting, but it's visible is by default. Clicking this button automatically closes any open JDataStores it can find. DBExceptionHandler
is the default dialog box displayed by dbSwing components when an exception occurs.
StorageDataSet
, you should almost always group them all inside data modules. Make any references to these StorageDataSet
s through DataModule
accessor methods such as businessModule.getCustomer()
. You should do this because much of the functionality surfaced through StorageDataSet
s is driven by property and event settings. Although most of the important structural StorageDataSet
properties are persisted in the JDataStore itself, the classes that implement the event listener interfaces aren't. By instantiating the StorageDataSet
with all event listener settings, constraints, calculated fields, and filters implemented with events, they are properly maintained at run time and design time.
DataStoreConnection
's readOnlyTx
property controls whether a transaction is read-only. This property must be set to true before the connection is open. For JDBC connections, it is controlled by the readOnly
property of the java.sql.Connection
object (returned by the java.sql.DriverManager.getConnection()
and com.borland.dx.dataset.sql.Database.getJdbcConnection()
methods).
Read-only transactions work by simulating a snapshot of the JDataStore. Only data from transactions committed at the point the transaction started are seen in this snapshot (otherwise, the connection would have to see if there are pending changes and roll them back whenever it accesses the data). A snapshot is taken when the DataStoreConnection
opens, and it refreshes every time its commit()
method is called.
Another benefit of read-only transactions is that they aren't blocked by writers (or other readers). Both reading and writing usually require a stream lock. But because a read-only transaction uses a snapshot, it doesn't need a lock. Therefore it won't be blocked by a writer that has a lock on a stream that it's modifying.
You can further optimize the application by specifying a readOnlyTxDelay
. By default, this property is zero, which means that whenever a read-only transaction starts or refreshes, a new snapshot is taken. The readOnlyTxDelay
property specifies the maximum age (in milliseconds) for an existing snapshot that the connection can share. When the property is non-zero, existing snapshots are searched from most recent to oldest. If there is one that is under readOnlyTxDelay
in age, it is used and no new snapshot is taken.
TxManager
's softCommit
property, the transaction manager forces disk writes for the purposes of crash recovery, but it doesn't guarantee transaction commits. This improves performance, but makes you slightly more susceptible to
power loss,
operating system crashes, and hardware failures.
Very recently committed transactions--depending on the operating system, but in general those committed within approximately the last second--aren't guaranteed to be written. This isn't the case when soft commit mode is disabled (the default), when committed changes are written immediately.
TxManager
's
ALogDir
and
BLogDir
properties control the location of the transaction log files.
You can duplex the log files by specifying a BLogDir
in addition to an ALogDir
to increase reliability. If either copy is damaged or lost, you have a backup.
Specify the directory for the BLogDir
on a different physical drive than the ALogDir
. This might reduce some of the performance penalty for writing two separate log files (both drives can write simultaneously), and it increases reliability because it's unlikely that both drives will fail.
recordStatus
property of the TxManager
to false.
com.borland.datastore.Tx*.class
If JDataStore is used without using the JDBC driver, exclude these classes:
StorageDataSet
.store
property is always set to an instance of DataStore
or DataStoreConnection
, exclude these classes:
com.borland.dx.memorystore.*
TableDataSet
is used, but not QueryDataSet
, QueryProvider
, StoredProcedureDataSet
or StoredProcedureProvider
, exclude these classes:
com.borland.dx.sql.*
com.borland.dx.text.*
com.borland.dx.dataset.TextDataFile
isn't used, exclude these classes:
com.borland.jb.io.*
com.borland.dx.dataset.TextDataFile.class
com.borland.dx.dataset.SchemaFile.class
jpgpubs@inprise.com
Copyright © 2000, Inprise Corporation. All rights reserved.