A JDO object is instantiated using the "new"
operator.
Calling Database.begin() opens a Castor transaction.
The new object is introduced to Castor by calling
Database.create(). This includes the JDO into the Castor
transaction. At the same time Castor creates the object
immediately in the current session of the database. It is now
called "persistent" regarding to the Castor transaction.
Calling Database.commit() ends the transaction, and the
object is now visible to any other session in the database.
The used JDBC session is closed also in this step.
After that the JDO is again "transient".
The final call to Database.close() only frees the used
memory of the Castor transaction.
JDO queries using OQL:
When executing an OQL query or by calling the function
Database.load() the returned objects are included as
"persistent" into the Castor transaction.
When finishing the transaction by calling commit() the
JDO changes are stored into the database.
Rollback:
If we call the function Database.rollback() instead of
commit(), the JDO changes are not stored into the database.
Instead the previous state is restored.
At the end of the canceled transaction the JDO is again
in the state "transient", and any changed properties are
reseted to their previous values.
Query JDO using OQL
in "read only" mode:
If an OQL query is executed in the "read only" mode, the
fetched objects are "transient".
If there are changes in the JDO, these won't be
transmitted into the database when finishing the transaktion,
may it be by calling commit() or by calling rollback().
Deleting Objects:
The call of Database.remove() marks a persistent JDO for
delete.
At commit time this object is deleted from the
database.
After that the JDO continues to exist in as "transient"
in the Java heap.
Update
using "long transactions":
In a so-called "long transaction" there is included an
object, which already exists in the database, into an open
Castor transaction by calling Database.update(). The
transient object typically originates out of a preceding
transaction. The "long transaction" thus joins two
independent Castor transactions by working with the same Java
object.
The object is now called "persistent" in regard to the
second transaction. This means changes in the object are
stored into the database when finishing the transaction with
a call to commit().
