Contents

• The Engines
• What's Released?
• The JDBC Engine
  • Notes
  • Database Compatability

The framework has been developed with the following Engine Types

Type 1 - JDO for Web Container

• This is based on Castor JDO
• It has support for managing the relationship between the domain objects
• It is based on JDBC connectivity
• Assumes Object Model is main driver

Type 2 - JDO for EJB Container (JBoss)

• This is based on Castor JDO
• Based on JBoss/Castor plug-in
• For use with the Session Bean/JDO strategy
• Assumes Object Model is main driver

Type 3 - Native JDBC Engine

• Based on O/R Mapping principles and Interceptor Chain
• Designed for use in Web Container
• Best Suited for Legacy Data Model Enablement
• Has additional tools for rapid web enablement of existing legacy data models

Type 4 - Native Entity Bean Engine

• Based on Entity Beans and Container Manager Persistence
• Uses the Session Bean to Local Entity Beans pattern
• Designed for use in a J2EE Container

Type 5 - Apache OJB (JDO) Engine

• Based on JDO (Java Data Objects) specification
• Uses the Apache OJB project as a JDO implementation

At present only the JDBC engine is commited into the project, this has now been testing and used in several production systems. We consider this a mature implementation.

Notes...

• Type 1 and 2 were developed, but still require large amounts of work to function 100% correctly.
• Type 1, 2 and 4 are best used in situations where you can design the object/data model from the ground up. This allows the object model to drive the final data model (not via versa). It also allows for things like technical keys (Object ID's) to be used, and allows good modeling of the database tables to the appropriate form to represent various inheritance models. All these strategies are intended to seamlessly support the manipulation and traversal of the persistent object model and manage the relationships constraints with the underlying implementation
• Type 3 is designed for web container use and intended for use with existing data models. Relies on programmatic ad hoc queries. Supports ACID transactions in a non-distributed environment.
• Type 5 is the next stage in the persistence evolution and we plan to move in this direction and in the process aim to make the functionality of this engine as lightweight as possible.

Supported Data Types Are

Supported Locking Strategies

• Optimistic (The record in the database will be locked, only when the persistent object is added to the database. This is the default locking strategy)
• Pessimistic (The record in the database will be locked, whenever a field is updated on the persistent object)
• Paranoid (The record in the database will be locked, at the instant it is read)
• ReadOnly (Read only access)

Other Features

• Support for execution of database stored procedures
• Supports database connection pooling
• 40+ Unit Test for validating ports to other JDBC 2.0 compliant databases
• Fully Tested on Oracle 8i and 9i
• Integrated with Data Security Architecture

Patterns

Current set of component patterns in the code generated are based on the domain objects using this engine

Performance Statistics

• Read on 1,000 records = 815 ms
• Write on 1,000 records = 1964 ms
• Read on 10,000 records = 6447 ms
• Write on 10,000 records = 19974 ms
• (Based on Linux 7.x / Oracle 9i / PIII-700Mhz / 768Mb)
• (Based on a Domain Object with 12 fields of various types)

Limitations

• Only supports LOB fields up to 4000 characters (Oracle)
• Only Support connection to a single database, all tables must be in that database
• The use of CHAR fields in the database prevent the correct execution of PreparedStatements(). This can be disabled, but there will be a performance impact of not using Prepared Statements.

Feature Wish List

• Full LOB support
• Support for 'DataSources' defined by the web container
• FieldList/VirtualProxies in retrieves. This would only bring partial data back to the domain object, and fetch other data on demand.
• A utility to validate all the mapping-files against database schema
• A utility to create database tables from mapping-files (Although if you use the domain object pattern generator it will produce a create table script)
• Supporting multiple database definitions in the init.xml, and adding the constructor 'UOW(String name)' to the class UOW.

The JDBC has been tested with the following databases... Oracle, MS SQL Server 2000, mySql, postgresSQL. Our primary database is Oracle, and as close as we can, we stick to the JDBC 2.0 specifcation, but for features like stored procedures, CLOBS, ARRAY parameters, etc we have to occationally implement some database specific features. If you what to be purely database agnostic, then we recommend that you don't use these advanced features, how ever in the reality of high performing business applications, these compromises are often made, so atleast we provide these facilities if you want them.

Compatability Issues

As our primary database is Oracle, there are no compatability issues with it.

MySQL

1. Could not find the 'Select... FOR UPDATE NOWAIT' feature, or its equivalent in mysql
2. The transactional support is missing in the default mysql download. It may however be supported in the InnoDB or BDB variants of mysql.
3. Stored Procedure support is missing. Its expected in MySQL 5.0
4. The 'testHitlist' UnitTest is failing, since MySQL seems to have a bug with the 'ESCAPE' clause. Its simply ignoring the ESCAPE character '|'

MS SQL Server 2000

1. Could not find the 'Select... FOR UPDATE NOWAIT' feature. However, the Microsoft documentation suggests using the hint 'UPDLOCK' and the setting 'LOCK_TIMEOUT 0' to achieve similar results.
2. The CLOB and BLOB datatypes are not present. Instead, use TEXT and IMAGE. The UnitTests related to CLOB and BLOB fields are failing.
3. A null value is being stored as a blank String in IMAGE fields, which causes the testUpdateRawAndLongRaw UnitTest to fail.
4. Stored Procedures have not been tested yet.

PostgreSQL

1. Could not find the 'Select... FOR UPDATE NOWAIT' feature, or its equivalent in postgresql
2. The UnitTests related to CLOB and BLOB fields are failing.
3. Stored Procedures have not been tested yet.