Appendix E. Implementation Notes
Prev |  | Next

## Appendix E. Implementation Notes

This appendix discusses implementation-specific details that may be important to developers.

## E.1. jdoFlags Fields in the Default Fetch Group

When loading the default fetch group fields into a `PersistenceCapable` object that is not involved in a transaction, Kodo JDO will set the jdoFlags field of the object to `READ_OK`. This means that subsequent read operations will not be mediated by the `StateManager`, reducing the number of method calls and therefore increasing performance.

When you modify a default fetch group field in a `PersistenceCapable` object that is involved in a transaction, Kodo JDO sets the jdoFlags field of the object to `READ_WRITE_OK`. This means that subsequent write operations to fields in the default fetch group will not perform checks against the data store, or otherwise access the `StateManager`. Additionally, when writing the data back out to the data store, all fields in the default fetch group will be written. This is because Kodo JDO does not intercept writes to fields in the default fetch group after they have been loaded, so it is impossible to know which of these fields have been modified. This may result in undesirable data store behavior, including unexpected firing of triggers. Explicitly removing elements from the default fetch group will resolve this.

See section 20.9.3 of the JDO specification for more details about this behavior.

Prev | Up | Next
D.5. Kodo 3 Development Process | Home | Appendix F. Development and Runtime Libraries