The Amber bean lifecycle follows the JDO 1.0 model. Amber supports both transactional and non-transactional lifecycles.
The lifecycle description uses a single running example, Test, which has two properties: getData() which returns a string, and getParent() which is a pointer to another Test object.
Amber's non-transactional lifecycle has three important states:
In the diagram below, the red methods (load(), getXXX(), and flush()) query and update the database.
The aConn.load("1") method loads the bean from the database and transitions to thestate.
Calling test.setData("foo") will change to thestate.
Calling aConn.flush() writes the changes to the database and changes to thestate. Amber may also flush the changes and change to the clean state at any time. flush() merely guarantees that the changes will be flushed to the database.
Thestate represents lazily-loaded entities. many-to-one relations and some queries will return the unloaded bean instead of a loaded bean. When the application calls a getXXX() method, the bean will load from the database and change to the state. When the application calls a setXXX() method, the bean will change to the state.
In a transaction, Amber loads the bean from the database, even if it was loaded outside of the transaction. (Exceptions exist for cases like read-only beans.) By loading the bean in the transaction, Amber lets the database handle the transactional locking and state consistency.
Just like the non-transactionaland states, Amber has transactional and states called and . As in the non-transactional case, the state represents lazily-loaded beans.
The main differences from the non-transactional lifecycle are: