- JDO implementations and vendors
- DO instances
- JDO environments
- Persistent vs. Transient
- Transactional vs. Non-transactional
- Support for transactional/persistent instances
- JDO identity
- What's next?
This chapter is from the book
This chapter is from the book
This chapter is from the book
JDO is a very thorough definition of object persistence. However, not all aspects of object persistence apply to all target data stores and applications. Thus, whilst the core features of JDO are required, many JDO features are declared to be optional. To be branded as JDO-compliant, an implementation must support all of the specification’s required features. Vendors are at liberty to choose which optional features they will support in order to best serve their target customer base.
The JDO specification states that support is required for instances which are persistent transactional. This is necessary in order to store data transactionally. Transient non-transactional instances are supported by default, as they are effectively standard Java objects and do not require management by JDO. The other two combinations – transient transactional instances and persistent non-transactional instances – are optional in JDO. If you intend to use them, you must select a JDO implementation that explicitly provides the required support (Table 3.2).
Table 3.2. Support for JDO implementations
|
Transient |
Persistent |
|
|---|---|---|
|
Non-transactional |
Unmanaged |
Optional |
|
Transactional |
Optional |
Required |
3.6.1 Transient transactional instances
A transient transactional instance is one that does not directly represent data in the data store but whose persistent and transactional field values the JDO Implementation will cache when the instance is first altered within a transaction. Upon commit() the cached field values will be discarded, but on rollback() the cached values will be restored into the instance’s fields.
The persistent fields are those that were deemed persistent by the enhancer, whether explicitly (by individual mention in the persistence descriptor) or implicitly (defaults being applied to fields that are not explicitly mentioned). Despite use of the term persistent, these values are not actually stored whilst the instance is transient.
Transient transactional instances might be used whenever a non-persistent Java class, being altered within a transaction, must have its state kept in sync with the state of persistent transactional instances being manipulated in the same transaction.
If the JDO implementation in use does not support transient transactional instances, an alternative approach would be to make use of the synchronization capabilities of the transaction object. Such an approach is, however, far more restrictive.
3.6.2 Persistent non-transactional instances
A persistent non-transactional instance is one which exists in the persistence manager’s cache but which is not necessarily consistent with the data store. They are used extensively in optimistic transactions.
The transaction interface, synchronization objects, and optimistic transactions are all discussed in Chapter 7.