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

  



Introduction
Bounded dirty checking

Introduction

The usual Castor transactions are called here short transactions: an object is read, modified and written within the bounds of one transaction. Long transactions consist of two Castor transactions: an object is read in the first and written in the second. Between them the object is sent "outwards" and modified there. For example, the object may be send to a client application and dispayed to a user, or it may be sent to a servlet engine and is displayed on a web page. After that the modified object returns back and is written to the database in the second transaction. At this point the object is usually not the same physical instance as one that was read in the first transaction. The example code for writing the object in the second Castor transaction follows:

             db.begin();
             db.update(object);
             db.commit();
         
Note, that if the object doesn't exist in the database, db.update(object) is equivalent to db.create(object). Also note, that it is natural to read the object in the first transaction in the read-only mode.

Since the time interval between the first and the second transaction is relatively big, it is desirable to perform dirty checking, i.e. to check that the object has not been modified in the database during the long transaction. For that the object must hold a timestamp: it is set by Castor during the first Castor transaction and is checked during the second one. In order to enable the dirty checking for long transactions, the object should implement the interface org.exolab.castor.jdo.TimeStampable having two methods:

long jdoGetTimeStamp()
and
void jdoSetTimeStamp(long timeStamp)
Note, that for a new objects jdoGetTimeStamp() must return 0, in this case db.update(object) acts as db.create(object). There are two types of timestamps: local (in the Castor cache) and global (in the database). Respectively, the are two dirty checking algorithms: bounded and reliable. They are decribed below in details. The reliable dirty checking isn't implemented yet.

Bounded dirty checking

The advantage of the bounded dirty checking is that it doesn't need any changes to the database schema, because it uses the Castor cache to store object timestamps. The disadvantage of this algorithm is that it is bounded by a lifetime of the cached copy of the object. After the cached copy has been purged, db.update() causes ObjectModifiedException.

Thus, parameters of the cache define dirty checking capabilities. Let's consider the existing cache types:

-none - the bounded dirty checking is impossible
-count-limited - the count limit for the cache is a count limit for the objects of this class that can participate in long and short transactions simultaneously.
-time-limited - the time limit for the cache is a time limit for the long transaction.
-unlimited - the bounded dirty checking gives correct results while the cache exists, i.e. until the crash of the server.

 
   
  
   
 


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.