JDO provides an interface to the persistence of objects. JDO 1.0 didn’t provide a way of taking an object that was just persisted and just work on it and update the persisted object later; the user had to copy the fields manually and copy them back to the persisted object later. JDO 2.0 introduced a new way of handling this situation, by detaching an object from the persistence graph, allowing it to be worked on in the users application. It could then be attached to the persistence graph later. Please refer to Object Lifecycle for where this fits in. The first thing to do to use a class with this facility is to tag it as “detachable”. This is done by adding the attribute

  1. <class name="MyClass" detachable="true">

This acts as an instruction to the enhancement process to add methods necessary to utilise the attach/detach process.

The following code fragment highlights how to use the attach/detach mechanism

  1. Product working_product=null;
  2. Transaction tx=pm.currentTransaction();
  3. try
  4. {
  5.     tx.begin();
  7.     Product prod=new Product(name,description,price);
  8.     pm.makePersistent(prod);
  10.     // Detach the product for use
  11.     working_product = (Product)pm.detachCopy(prod);
  13.     tx.commit();
  14. }
  15. catch (Exception e)
  16. {
  17.     // Handle the exception
  18. }
  19. finally
  20. {
  21.     if (tx.isActive())
  22.     {
  23.         tx.rollback();
  24.     }
  25. }
  27. // Work on the detached object in our application
  28. working_product.setPrice(new_price);
  30. ...
  32. // Reattach the updated object
  33. tx = pm.currentTransaction();
  34. try
  35. {
  36.     tx.begin();
  38.     Product attached_product = pm.makePersistent(working_product);
  40.     tx.commit();
  41. }
  42. catch (Exception e)
  43. {
  44.     // Handle the exception
  45. }
  46. finally
  47. {
  48.     if (tx.isActive())
  49.     {
  50.         tx.rollback();
  51.     }
  52. }

So we now don’t need to do any manual copying of object fields just using a simple call to detach the object, and then attach it again later. Here are a few things to note with attach/detach :

  • Calling detachCopy on an object that is not detachable will return a transient instance that is a COPY of the original, so use the COPY thereafter.

  • Calling detachCopy on an object that is detachable will return a detached instance that is a COPY of the original, so use this COPY thereafter

  • A detached object retain the id of its datastore entity. Detached objects should be used where you want to update the objects and attach them later (updating the associated object in the datastore. If you want to create copies of the objects in the datastore with their own identities you should use makeTransient instead of detachCopy.

  • Calling detachCopy will detach all fields of that object that are in the current Fetch Group for that class for that PersistenceManager.

  • By default the fields of the object that will be detached are those in the Default Fetch Group.

  • You should choose your Fetch Group carefully, bearing in mind which object(s) you want to access whilst detached. Detaching a relation field will detach the related object as well.

  • If you don’t detach a field of an object, you cannot access the value for that field while the object is detached.

  • If you don’t detach a field of an object, you can update the value for that field while detached, and thereafter you can access the value for that field.

  • Calling makePersistent will return an (attached) copy of the detached object. It will attach all fields that were originally detached, and will also attach any other fields that were modified whilst detached.

Detach All On Commit

JDO also provides a mechanism whereby all objects that were enlisted in a transaction are automatically detached when the transaction is committed. You can enable this in one of 3 ways. If you want to use this mode globally for all PersistenceManager_s (PMs) from a _PersistenceManagerFactory (PMF) you could either set the PMF property “datanucleus.DetachAllOnCommit”, or you could create your PMF and call the PMF method setDetachAllOnCommit(true). If instead you wanted to use this mode only for a particular PM, or only for a particular transaction for a particular PM, then you can call the PM method setDetachAllOnCommit(true) before the commit of the transaction, and it will apply for all transaction commits thereafter, until turned off (setDetachAllOnCommit(false). Here’s an example

  1. // Create a PMF
  2. ...
  4. // Create an object
  5. MyObject my = new MyObject();
  7. PersistenceManager pm = pmf.getPersistenceManager();
  8. Transaction tx = pm.currentTransaction();
  9. try
  10. {
  11.     tx.begin();
  13.     // We want our object to be detached when it's been persisted
  14.     pm.setDetachAllOnCommit(true);
  16.     // Persist the object that we created earlier
  17.     pm.makePersistent(my);
  19.     tx.commit();
  20.     // The object "my" is now in detached state and can be used further
  21. }
  22. finally
  23. {
  24.     if (tx.isActive)
  25.     {
  26.         tx.rollback();
  27.     }
  28. }

Copy On Attach

By default when you are attaching a detached object it will return an attached copy of the detached object. JDO2.1 provides a new feature that allows this attachment to just migrate the existing detached object into attached state.

You enable this by setting the PersistenceManagerFactory (PMF) property datanucleus.CopyOnAttach to false. Alternatively you can use the methods PersistenceManagerFactory.setCopyOnAttach(boolean flag) or PersistenceManager.setCopyOnAttach(boolean flag). If we return to the example at the start of this page, this now becomes

  1. // Reattach the updated object
  2. pm.setCopyOnAttach(false);
  3. tx = pm.currentTransaction();
  4. try
  5. {
  6.     tx.begin();
  8.     // working product is currently in detached state
  10.     pm.makePersistent(working_product);
  11.     // working_product is now in persistent (attached) state
  13.     tx.commit();
  14. }
  15. catch (Exception e)
  16. {
  17.     // Handle the exception
  18. }
  19. finally
  20. {
  21.     if (tx.isActive())
  22.     {
  23.         tx.rollback();
  24.     }
  25. }

Please note that if you try to attach two detached objects representing the same underlying persistent object within the same transaction (i.e a persistent object with the same identity already exists in the level 1 cache), then a JDOUserException will be thrown.

Serialization of Detachable classes

During enhancement of Detachable classes, a field called jdoDetachedState is added to the class definition. This field allows reading and changing tracking of detached objects while they are not managed by a PersistenceManager.

When serialization occurs on a Detachable object, the jdoDetachedState field is written to the serialized object stream. On deserialize, this field is written back to the new deserialized instance. This process occurs transparently to the application. However, if deserialization occurs with an un-enhanced version of the class, the detached state is lost.

Serialization and deserialization of Detachable classes and un-enhanced versions of the same class is only possible if the field serialVersionUID is added. It’s recommended during development of the class, to define the serialVersionUID and make the class to implement the java.io.Serializable interface, as the following example:

  1. class MyClass implements java.io.Serializable
  2. {
  3.     private static final long serialVersionUID = 2765740961462495537L; // any random value here
  5.     //.... other fields
  6. }