During the persistence process, an object goes through lifecycle changes.
Below we demonstrate the primary object lifecycle changes for JDO
JDO has a very high degree of flexibility and so can be configured to operate in
different modes. The mode most consistent with JPA is shown below (this has the
PMF property
DetachAllOnCommit
set to true)
So a newly created object is
transient
. You then persist it and it becomes
persistent
. You then commit the transaction and it is detached for use elsewhere
in the application. You then attach any changes back to persistence and it becomes
persistent
again. Finally when you delete the object from persistence and commit
that transaction it is in
transient
state.
An alternative JDO lifecycle occurs when you have
DetachAllOnCommit
as false.
Now at commit the object moves into
hollow
state (still has its identity, but its
field values are optionally unloaded).
With JDO there are actually some additional lifecycle states, notably when an
object has a field changed, becoming
dirty
, so you get an object in
"persistent-dirty", "detached-dirty" states for example. The average user doesn't need
to know about these so we don't cover them here. To inspect the lifecycle state of an
object, simply call
JDOHelper.getObjectState(obj);
In addition to the JDOHelper method above, JDO provides a series of other helper methods for
lifecycle operations.
These are documented on the Apache JDO site.
Further to this DataNucleus provides yet more helper methods
String[] fieldNames = NucleusJDOHelper.getDirtyFields(pc, pm);
String[] fieldNames = NucleusJDOHelper.getLoadedFields(pc, pm);
These methods returns the names of the dirty/loaded fields in the supplied object.
The
pm
argument is only required if the object is detached
Boolean dirty = NucleusJDOHelper.isDirty(pc, "fieldName", pm);
Boolean loaded = NucleusJDOHelper.isLoaded(pc, "fieldName", pm);
These methods returns whether the specified field in the supplied object is dirty/loaded.
The
pm
argument is only required if the object is detached
