This chapter discusses the lifecycle of objects and the reasons why state changes can be meaningful to the application developer. Why are object lifecycles and state transitions important to know? Imagine what happens inside of a JVM whenever "new" is called by an application: A small portion of memory needs to be allocated and a reference is returned to the application, but the world is more complex behind the scenes. First, the JVM might load the byte code from some resource and then compile the byte code to native machine instructions. Then static initialization takes place, the base classes are loaded, and constructors are called. Even more complex is the destruction of memory instances due to garbage collection, weak references, queues, and finalize callbacks. There must be some well-defined lifecycle model inside the JVM that lets Java objects be used predictably and without "Deep Thought." As Java instances in memory have their lifecycle, persistent instances in JDO have a similar one: Its life starts as a plain, transient Java object, and it can become persistent, can be deleted, can be made transient again, and so on. Knowing about the object's persistent lifecycle is not needed in general, especially in every little detail, but whenever callbacks or other re-entrant code is used, it is strongly recommended that you think about the side effects of state transitions. First, we present a brief introduction into mandatory and optional states of instances, the methods to gather information about states, and methods that lead to state transitions. Java source code is provided to illustrate state changes and to print state information about persistent instances. A section about instance callbacks explains their use and conditions. Last, optional states and operations are explained. |