DataCaster Release Notes (Preview Release 0.96)

DataCaster is a new product at a Pre-Beta stage. This is only a subset of the known issues and limitations. The full list for such a product is much longer, and hard to put together at this stage. The following captures many of the limitations you may experience when using the product for some of the typical applications for DataCaster.

Limitations

  • No support for nested transactions.
  • No support for distibuted transactions.
  • No data encryption.
  • No support for ODBC.
  • No support for incremental archives.
  • Limited support for SQL triggers.(Only table level triggers are supported. Conditional triggers at tuple level, not yet supported).
  • The RMI User API driver has a number of limitations relative to the embedded driver. A number of remote methods are not yet supported.
  • BLOB/CLOB support is limited, including no transaction log recovery. Problems exist with update of tuples containing BLOB/CLOB on linux machines.
  • Defragmentation is not yet supported for the TEXT type LOB file, and the LOB file just keeps growing.
  • Database replication does not support schema changes, and all schema changes must be performed at the proper time for each database separately.
  • Support for large tables combining table fragments is still under test, and is currently undocumented.

Jdbc Limitations
  • No JDBC Result Set update support.
  • Returning multiple restuts from a statement is not implemented.
  • Support for named parameters not complete.
  • TypeMaps and Savepoints are not supported.
  • Batch updates are not supported.
  • Cursors in resultsets are not supported.

Read jdbcGuide for detailed list of limitations.

RMI Limitations
  • Only serializable objects and RMI objects can be passed as values to RMI objects.
  • Encrypted transfer of data is not supported.
  • On the server the database connetions are usually kept alive for a longer period to server the client requests.

WebAdmin Limitations
  • To support connection timeout (for long running command), the page communicates with the server every few seconds, like in Jython Scripting, although you can 'Cancel Request' in the middle, some issues might arise which can lock the database.

Known Issues

  • Table scan performance is poor due to NIO Buffer allocation costs, and buffer pooling needs to be implemented soon to fix this.
  • A number of queries are not optimized.
    Eg. Some of the nested conditions like OR within AND is not optimized - say condition1 AND (condition2 OR condition3).
    Whereas some other nested conditions like AND within OR or multiple level nested OR conditions or multiple level nested AND conditions are optimized.
  • Certain DDL (schema changes, index additions, etc.) statements and API operations are automatically commited, typically when dealing with large tables. This may be to avoid long-term locks when possible, or other reasons. Applications will need to be prepared for this by re-obtaining the current transaction and not using an earlier reference to any transaction created prior to the DDL statement.
  • Memory management for TEXT type data is not available, and can cause memory considerably in excess of the configured index page caches, particularly if the average TEXT values are large.
  • Granting SCHEMA level CREATE access to a user on a given schema, allows the user to grant him/herself access to existing tables in the schema.
  • Integrated text search with Lucene has a number of limitations when the tab;le sizes get too large. It works well enough upto about 10 mil rows, beyond which the search index optimize delays and other issues start to make it more difficult to work with.
  • Table counts (number of tuples) are maintained for each table, but are not stored for each transaction. Hence the count obtained for each table may be ditry (i.e. may not be commited). Table counts may be isolated for each transaction using a template parameter, but that can slow down queries dramatically for large tables.
  • Cascade referential action, ON CASCADE, is not working right now. It doesn't throw any exception. But the tuples in the foreign key table are not updated as per the tuples of Referenced table. This will create data inconsistency between the referenced table and referencing table.
  • Some of the deadlocks situations are not handled for Triggers. (Direct deadlock of triggers between two tables is handled. But a number of triggers forming a loop around the tables, might cause deadlock which is not handled).
  • Database replication terminates without cause on occasion. The cause is still being investigated.
  • Restore for the view "COLUMNS" in INFORMATION_SCHEMA fails.
  • When recovery is performed on an improperly shutdown database, it is normal to see error logs of the type: "Log entry decode failure"