db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Lai" <t...@leversoft.com>
Subject Re: Questions on detach/attach and setDetachAllOnCommit
Date Tue, 29 Nov 2005 06:18:25 GMT
Hi Graig,

Thank you for your answers.  Let me clearify a little thing here.  I only define the fetch-group
"group1" because the fetch-depth defined in the class field does not work, and JPOX developers
(Andy in this case) is not clear what the expectation is since it is not defined in the spec.
 Can you add a little clearification to the spec on this issue, please?

I still have a few questions on your statement:
  Well, it is still detached, it still has its version number and state, but it's now stale
(it can't realistically be used further), and it's therefore not much use. If you are going
to use instances after the commit, they should be from the instance graph that was most recently
detached.
Not just the original parent instance become useless, but also the child1 since it is pointing
to that parent.  Therefore if I want to have a valid child1 after child2 is saved, I need
to include child1 as part of the makePersistentAll call, and then re-assign child1 to the
new copy.
  This scenario only works if the cache never contains instances with the same persistent
object id as instances to be attached. And there are issues with rollback of detached instances
that are attached in place.
Wouldn't that be a bigger problem if you attachCopy an object to a PM containing an instance
with the same persistent object id in its cache already?  For example.  After the first makePersistent
call to child1, I can:
  tx.begin();
  pm.makePersistent(child2);
  pm.attachCopy(child1);
  tx.commit();
Should I get an exception on my attachCopy(child1) call because I am attaching the parent
that is already in the cache?  But I am not attaching the parent.  It just happen to be referenced
by both children.  If the parent is attached (not a copy) to the cache, at least we know the
parent is attached already, and there is no need to attach it again in the secode call.  I
know I can call makePersistentAll(new Object[]{child1, child2}).  I just want to make my point
that attaching the original object should not create additional problems.  Rollback a detached
instance should be easier too, so I believe.  Just make a copy before the attach, and restore
the content in a rollback.

I understand there are cases that attaching a copy is required, but attaching the original
may reduce some unnecessary code.  Why don't you provide both, and let the developers choose
which one to use?

Regards,
Tony
----- Original Message ----- 
  From: Craig L Russell 
  To: Tony Lai ; Apache JDO project ; JDO Expert Group 
  Sent: Monday, November 28, 2005 7:09 PM
  Subject: Re: Questions on detach/attach and setDetachAllOnCommit


  Hi Tony,


    Here are the questions:

    1. Should the fetch-depth="0" defined in the class->field work? 



  Both the field-defined fetch-depth and the group1-defined fetch-depth are 0. So it's not
clear what you mean.


    It does not have any effect right now in JPOX, but again, the spec does not say anything
about how this should work. I have to define a fetch-group, so I can use the fetch-depth feature.




  No, you can use fetch-depth on a field. And you do in your example.
  <!ATTLIST field fetch-depth CDATA #IMPLIED>


   If you omit the fetch-group group1 from your example, the default fetch group should fetch
the parent(s) recursively.


    What my assumption is "this is the default fetch-depth, which can be overridden by field
fetch-depth definition in individual groups." Anyone have any idea?



  Yes, the fetch-depth in the field definition can be overridden by the fetch-depth in individual
groups.


    2. When I save the first child, the parent and grandparent are also saved. Since all 3
objects were transient before the makePersistent call, they should be in detached state as
the spec 13.4.2 said. 



  Right. First they are made persistent by reachability and then they are detached in place.


    Now I changed the parent's name to David, and call makePersistent on child2 having the
same parent. Is this legal? 



  It is not legal according to the Proposed Final Draft, but it is legal according to a change
the expert group just approved. With the change, attachCopyAll no longer exists and you use
makePersistentAll to attach objects or make transient objects persistent. So your usage is
correct here.


    or should I call attachCopyAll instead? If it is legal, then what should happen here?
The spec has no definition what to expect to a detached-dirty object referenced by the target
object. Should JDO save the parent's name?



  Yes. Once JPOX code base has been updated to reflect the latest spec change, attaching a
dirty-detached object will affect the cache, and the dirty object should be committed to the
database as well as the newly created child2.


    3. What should be the object referenced by the parent field of child2 after the save?




  When you called makePersistentAll on child2, it became persistent and a copy of its parent
was put into the cache. And when you committed the transaction, the instances in the cache
were detached. So the parent of child2 is a detached instance that has the new name and is
distinct from the original parent.


    Note it is detach-all-on-commit. Should it be the original parent instance, or a new detached-clean
instance? If it is later case, then the original detached parent instance become useless.




  Well, it is still detached, it still has its version number and state, but it's now stale
(it can't realistically be used further), and it's therefore not much use. If you are going
to use instances after the commit, they should be from the instance graph that was most recently
detached.


    Would not be better to have an attach method let the PM manage the instance, so we can
get it back after the transaction is committed, using detach-all-on-commit or a detach method?



  This scenario only works if the cache never contains instances with the same persistent
object id as instances to be attached. And there are issues with rollback of detached instances
that are attached in place.


    4. What kind of instances should I got back from my listAll method? detached-clean or
hollow? 



  Regardless of whether the commented-out method is called, you will get detached instances.
The effect of the commented-out method is that it creates a copy of the cached instances and
detach-all-on-commit doesn't create a copy but detaches in place.


    According to my understanding of detach-all-on-commit, they should be detached-clean,
am I right? Do I need to call detachCopyAll to get the detached instances?



  There is no need to call detachCopyAll for this case.


    Thank you for your help in advance!



  You are welcome in arrears.


  Craig


    Tony
  On Nov 28, 2005, at 6:52 AM, Tony Lai wrote:


    Hi,

    Since these questions are about the spec, I hope someone from the expert group can give
me the answers.  This is also posted on JDOCentral's forums http://www.jdocentral.com/forums/index.php?s=37b48c123ee46e821f97901d00afaeeb&showtopic=1590.

    First, let me define a couple simple classes for demo purpose.

          CODE 
          public class Person implements DetachCallback {
             private String name;
             private Person parent;
             
             public Person(String name) {
                 this(name, null);
             }
             public Person(String name, Person parent) {
                 this.name = name;
                 this.parent = parent;
             }
             ...getters and setters...

             public String toString() {
                 String parentStr = null;
                 try {
                     Person myParent = getParent();
                     if(myParent != null) {
                         parentStr = myParent.toString();
                     }
                 } catch(Exception x) {
                     //may be caused by field not loaded.  Ignore it for now
                 }
                 return name +"["+System.identityHashCode(this)+"]"+
                     (parentStr == null ? "" : (" parent: " + parentStr));
             }

             public void jdoPreDetach() {}
             public void jdoPostDetach(Object detached) {
                 System.out.println("jdoPostDetach: "+name);
             }
          }

          public class DetachTest {
             protected PersistenceManager pm;

             Person grandParent = new Person("Bob");
             Person parent = new Person("Dave", grandParent);
             Person child1 = new Person("John", parent);
             Person child2 = new Person("Mary", parent);
             
             public DetachTest () {
                 pm = createPersistenceManager();
                 pm.setDetachAllOnCommit(true);
             }
             
             public void test() {
                 //This should save child1, parent, and grandParent.
                 makePersistent(child1);
                 System.out.println(child1);

                 // Now change the parent name
                 parent.setName("David");
                 makePersistent(child2);
                 System.out.println(child2);
                 
                 System.out.println();
                 List list = listAll(Person.class, true, "group1");
                 
                 for (Iterator i = list.iterator(); i.hasNext();) {
                     Object obj1 = i.next();
                     System.out.println("    item: "+obj1);
                 }
              }
             
             public static void main(String[] args) {
                 new DetachTest ().test();
             }

             public void makePersistent(Object obj) {
                 Transaction tx = pm.currentTransaction();
                 try {
                     tx.begin();
                     pm.makePersistent(obj);
                     tx.commit();
                 } finally  {
                     rollbackIfActive(tx);
                 }
             }

             public List listAll(Class targetClass, String fetchGroup) {
                 Transaction tx = pm.currentTransaction();
                 Extent extent = null;
                 try {
                     tx.begin();
                     pm.getFetchPlan().setGroup(fetchGroup);

                     List data = new ArrayList();
                     extent = pm.getExtent(targetClass,false);

                     for (Iterator i = extent.iterator(); i.hasNext();) {
                      Object obj1 = i.next();
                      data.add(obj1);
                     }
                     //data = (List)pm.detachCopyAll(data);  // see question 4

                     tx.commit();
                     return data;
                 }  finally {
                     closeIterators(extent);
                     rollbackIfActive(tx);
                 }
             }
             ... some helper methods...
          }

          <jdo>
            <package name="test.jpox.detach">
               <class name="Person" detachable="true">
                  <field name="parent" default-fetch-group="true" fetch-depth="0"/>

                  <fetch-group name="group1">
                   <fetch-group name="default"/>
                     <field name="parent" fetch-depth="0"/>
                  </fetch-group>
               </class>
          </package>
          </jdo>

         





  Craig Russell

  Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

  408 276-5638 mailto:Craig.Russell@sun.com

  P.S. A good JDO? O, Gasp!



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message