ExoLab     OpenEJB     OpenJMS     OpenORB     Castor     Tyrex     
 

Main
  Home
  Download
  API
  Schema
  Mailing Lists
  CVS

XML
  Using XML
  Source Generator
  Schema Support
  XML Mapping

JDO
  Using JDO
  New features
  JDO Config
  Types
  FAQs
  Presentation

Advanced JDO
  OQL
  Trans. & Locks
  Design
  KeyGen
  Long Trans.
  Nested Attrs.

More
  Presentations
  The Examples
  Configuration
  Tips & Tricks
  Full JavaDoc

About
  License
  Contributors
  Status, Todo
  Changelog
  Library
  Contact

  



Logging and Tracing
JDO: Access Mode
JDO: Inheritence
XML: Indentation
XML:Marshall validation
JDO: Views of Same Object
JDO: Upgrading Locks
XML/JDO: Create method

Logging and Tracing

When developing using Castor it is recommended to use the various setLogWriter methods to get detailed information and error messages.

Using a logger with org.exolab.castor.mapping.Mapping will provide detailed information about mapping decisions made by Castor, as well as show the SQL statements being used.

Using a logger with org.exolab.castor.jdo.JDO will provide trace messages showing when Castor is loading, storing, creating and deleting objects. All database operations will appear in the log. If an object is retrieved from the cache or not modified, there will be no trace of load/store operations.

Using a logger with org.exolab.castor.xml.Unmarshaller will provide trace messages showing conflicts between the XML document and loaded objects.

A simple trace logger can be obtained from org.exolab.castor.util.Logger. This logger uses a standard output stream, but prefixs each line with a short message that indicates who generated it. It can also print the time and date of each message. Since logging is used for warning messages and simple tracing, Castor does not require a sophisticated logging mechanism.

JDO: Access Mode

If you are using JDO objects with the default access mode ('shared') and too many transactions abort when attempting to commit due to locks, you should consider upgrading to an 'exclusive' mode. When two transactions attempt to modify and store the same object at the same time, lock issues arise. Upgrading to an 'exclusive' mode will prevent concurrent transactions from modifying the same object at once.

If too many transactions abort when attempting to commit due to dirty checking, you should consider upgrading to a 'locked' mode. When external database access modifies the same objects being managed by Castor, Castor will complain that objects are dirty. Upgrading to a 'locked' mode will prevent concurrent update.

Be advised that 'exclusive' mode introduces lock contention in the Castor persistence engine, and 'locked' mode adds lock contention in the database. Lock contention has the affect of slowing down the application and consuming more CPU.

If too many transaction abort due to deadlock detection, consider modifying the application logic. Deadlock occurs when two transactions attempt to access the same objects but not in the same order.

JDO: Inheritence

There are two types of inheritence: Java inheritence and relational inheritence.

With Java inheritence two objects extend the same base class and map to two different tables. The mapping file requires two different mappings for each of the objects. For example, if Employee and Customer both extend Person, but Employee maps to the table emp and Person to the table person, the mapping file should map both of these objects separately.

With relation inheritence, one table provides the base information and another table provides additional information using the same primary keys in both. Use the extends attribute to specify such inheritence in the mapping file. For example, if Computer extends Product and the table comp provides computer-specific columns in addition to product columns in prod, the mapping for Computer will specify Product as the extended class.

When a class just extends a generic base class or implements an interface, this form of inheritence is not reflected in the mapping file.

XML: Indentation

By default the marshaller writes XML documents without indentation. When developing using Castor or debugging it might be desireable to use indentation to make the XML documents more readable. To turn indentation on, modify the Castor properties file, or create a new properties file in the classpath (named castor.properties) with the following content:

org.exolab.castor.indent=true
         

Indentation inflates the size of the generated XML documents, and also consumes more CPU. It is recommended not to use indentation in a production environment.

XML:Marshall validation

It is possible to disable the validation in the marshalling framework by simply modifying the Castor properties file or create a new properties file in the classpath (named castor.properties) with the following content:

org.exolab.castor.marshalling.validation=true
         

JDO: Views of Same Object

It is possible to use different objects and mappings to the same tables. For example, it is possible to define a subset of a table and load only several of the columns, or load an object without it's relations.

To determine the first and last names and e-mail address of an object without loading the entire person object, create a subset class and map that class to a portion of the table. Such a class cannot be used to create a new person, but can be used to delete or modify the person's details.

Use partial views with care. If you attempt to load the same record using a full object and a subset object, changes to one of these objects are allowed, but changes to both will result in a conflict and roll back the transaction. Locking will not work properly between full and subset objects. Also note, that each of the too objects will have its own cache, so if you update the first object and load the second, you may obtain old values. To avoid this situation you may turn off the cache for both objects:

             
                
                ...
             
         

JDO: Upgrading Locks

When an object is loaded into memory in the default access mode ('shared'), a read lock is acquired on that object. When the transaction commits, if there are changes to the object, a write lock will be required. There is no guarantee that a write lock can be acquired, e.g. if another transaction attempts to change the same object at the same time.

To assure concurrent access, you may upgrade the object's lock by calling the lock(java.lang.Object) method. This method will acquire a write lock, or return if a timeout passed and the lock could not be acquired. Once a lock has been acquired, no other transaction can attempt to read the object until the current transaction completes.

Object locking is recommended only if concurrent access results in conflicts and aborted transactions. Generally locks results in lock contention which has an affect on performance.

XML/JDO: Create method

 
   
  
   
 


Copyright © 1999-2001 ExoLab Group. All rights reserved.
 
Java, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. XML, XML Schema, XSLT and related standards are trademarks or registered trademarks of MIT, INRIA, Keio or others, and a product of the World Wide Web Consortium. All other product names mentioned herein are trademarks of their respective owners.